locked
Data Access Layer inheritance RRS feed

  • Question

  • User1206668584 posted

    Hello

    We have three different (web)clients which all access the same MS SQL database.

    Currently all clients are using the same Data Access Layer, but that gives us some problems when different clients needs different results and/or different input for the "same" query.Today we need to implement that as different methods in the DAL.

     So I was thinking; is it possible to create data access layers which inherit from another data access layer, so that we could create the following structure;

     1. Basic data access layer, which contains tables and table adapters which is used in all clients

    2. A data access layer for each client, which inherits for the Basic data access layer, so clients have access to all tables and adapters defined in the current data access layer and the "Basci" data access layer.

    Is this possible or is there another practice for doing this?

    Regards

      Jesper Lauridsen

    Friday, July 18, 2008 5:43 AM

Answers

  • User-503940700 posted

    So I was thinking; is it possible to create data access layers which inherit from another data access layer, so that we could create the following structure;
     

    Do not use inheritance in DAL layer, it is simply a utility layer and should not have much OO in it, infact it would be good if you have static methods in it. Let the methods have different signatures or you can create a SearchObject class with different parameters and pass that object in the DAL methods to avoid creating multiple methods. But again it would involve complexity which can be avoided by keeping things simple.

    HTH,

    Vivek 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, July 19, 2008 11:26 PM
  • User-525215917 posted
    In one of my current projects I am using search DTOs to specify search criteria for different searches. The site we are building has not much different ways to make searches. Search DTOs have their own price because query building is not very simple anymore but programmers on UI side are happy. When they need some search they create search DTO specific to this page or part of site, assign values to parameters they have and then call search method with that DTO. We put search methods in services library, so we have can deploy all search and other services separately from main system. Also DAL and repositories are in separate libraries. One fictional example of search DTO:
    public class ProductSearchDTO
    {
        public string SearchProductName { get; set; }
        public string SearcgProductDescription { get; set; }
        public int? SearchProductId { get; set; }
        public int? SearchManufacturerId {get; set; }
        public IList<int> SearchProductCategories { get; set; }
    }
    
    This DTO is given to search service and service returns the results. Something like this:
     ProductSearchDTO dto = new  ProductSearchDTO();
    
    // Assign values to DTO properties
    
    IProductSearchService service = IOContainer.Resolve<IProductSearchService>();
    IList<Product> products = service.Search(dto);
    
    productsListView.DataSource = products;
    productsListView.DataBind();
    
    One thing you should handle carefully: don't let those DTOs grow too large. If they grow too large it is hard to examine them and analyze impossible query conditions.
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, July 20, 2008 7:49 AM

All replies

  • User-236164021 posted

    So, what i understand is you are running into a situation where client A needs to fetch Employees by ID, client B needs to fetch Employees matching a particular Last Name and so you create seperate methods in the EmployeeDAL to serve these clients.

    If we go with the above example, I would create a EmployeeQueryOptions enum that enumerates the properties of my Employee business object. The DAL method GetEmployees() should accept Employee object as an input paramter rather than Employee ID or Last name. So, if i want to query the Employees table by Employee Last Name and Designation, I would create a new Employee object, populate Last Name and Designation properties and feed this Employee object into GetEmployee method. Now, how does DAL.GetEmployees() method know which properties of Employee object should be used in the WHERE clause in the database query. Thats where our EmployeeQueryOptions enum comes in. The GetEmployees method should accept an additional parameter of type EmployeeQueryOptions that lets the method know which properties of the input Employee object to use for building the WHERE clause of the database query. 

    So, your DAL will look like

    public List<Employee> GetEmployees(Employee objMatchThisEmployee, EmployeeQueryOptions optMatchCriteria); //build the WHERE clause for database query in the method using optMatchCriteria

    public List<Employee> GetEmployees(Employee objMatchThisEmployee, EmployeeQueryOptions optMatchCriteria, EmployeeQueryOptions optFieldsToBeFetched); //If you want the client to specify what columns/fields he needs use this overload

    public List<Employee> GetEmployees(); //Gets all employees by internally calling one of the above overloads

     

    This way, to serve all possible client requests, you would just three overloads at max.

     

     

    Friday, July 18, 2008 2:52 PM
  • User-503940700 posted

    So I was thinking; is it possible to create data access layers which inherit from another data access layer, so that we could create the following structure;
     

    Do not use inheritance in DAL layer, it is simply a utility layer and should not have much OO in it, infact it would be good if you have static methods in it. Let the methods have different signatures or you can create a SearchObject class with different parameters and pass that object in the DAL methods to avoid creating multiple methods. But again it would involve complexity which can be avoided by keeping things simple.

    HTH,

    Vivek 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, July 19, 2008 11:26 PM
  • User-525215917 posted
    In one of my current projects I am using search DTOs to specify search criteria for different searches. The site we are building has not much different ways to make searches. Search DTOs have their own price because query building is not very simple anymore but programmers on UI side are happy. When they need some search they create search DTO specific to this page or part of site, assign values to parameters they have and then call search method with that DTO. We put search methods in services library, so we have can deploy all search and other services separately from main system. Also DAL and repositories are in separate libraries. One fictional example of search DTO:
    public class ProductSearchDTO
    {
        public string SearchProductName { get; set; }
        public string SearcgProductDescription { get; set; }
        public int? SearchProductId { get; set; }
        public int? SearchManufacturerId {get; set; }
        public IList<int> SearchProductCategories { get; set; }
    }
    
    This DTO is given to search service and service returns the results. Something like this:
     ProductSearchDTO dto = new  ProductSearchDTO();
    
    // Assign values to DTO properties
    
    IProductSearchService service = IOContainer.Resolve<IProductSearchService>();
    IList<Product> products = service.Search(dto);
    
    productsListView.DataSource = products;
    productsListView.DataBind();
    
    One thing you should handle carefully: don't let those DTOs grow too large. If they grow too large it is hard to examine them and analyze impossible query conditions.
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, July 20, 2008 7:49 AM
  • User-1548088970 posted
    infact it would be good if you have static methods in it
    .  Perhaps I should open this up in another thread, but are there any disadvantages to creating a static DAL? I have read several posts that state it's not a good practice; however, I can't seem to figure out why.  IMO, a static DAL makes more sense and since requests are spawned in different threads anyways and database engines handle all of the connections, I don't see any wait/locking issues with it. If it involves a lot of discussion, I'll open a new thread.
    Monday, July 21, 2008 8:56 PM
  • User-503940700 posted

    Perhaps I should open this up in another thread, but are there any disadvantages to creating a static DAL? I have read several posts that state it's not a good practice; however, I can't seem to figure out why.
     

    Static DAL methods have no issues at all, unless you want to code for multiple databases and want to use Dependency Injection/Factory Methods. Then your methods cant be static as you will need to use interfaces.

    There is no performance impact and I have used static dal methods in very big projects.

    Vivek 

    Monday, July 21, 2008 11:14 PM
  • User-153021614 posted

    The disadvantage you probably see with static dependencies is that they make unit testing trickier you can resolve this by IoC. There is a good series of posts on los techies I would recommend that demonstrates achieving this:

  • Separation of Concerns - how not to do it
  • Separation of Concerns by example: Part 1 - Refactoring away from static class
  • Separation of Concerns by example: Part 2 - Specialized interface for Cache
  • Separation of Concerns by example: Part 3 - Creating the repository
  • Separation of Concerns by example: Part 4 - Fixing a bug with unit tests 

     

Tuesday, July 22, 2008 3:54 AM
  • User-1548088970 posted

    I guess I am mostly concerned with this post [ http://forums.asp.net/p/908244/1010515.aspx#1010515 ].  A few people mention that instance based would be the way to go while others say that static is fine, and others state that singleton is a way to go. The .NET Pet Shop uses singleton and I have to believe that it would work fine in an Enterprise environment. It takes advantage of polymorphism by being to swap out DAL's at runtime and at the same it's efficient because it will only load one instance for each domain.

    I know that most DAL's can be generated via ORM's; however, I have always been confused on the best pattern/route to take.  I have to believe that there is a distinct answer since the DALs should always have the same functionality/role. So, it looks like there are issues with dependencies with static DAL's, but these can be relieved with a little work. What disadvantages/advantages do singleton and instanced DAL's have compared to a static DAL. Thanks!!

     

    Tuesday, July 22, 2008 8:59 AM
  • User-525215917 posted
    .Net Pet Shop has nothing to do with architecture. It is built up from zero to beat similiar Java example application in performance. If you need architecture then forget the .Net Pet Shop. Using mappers is great idea because a lot of complex code is already written and tested for you. I am using NHibernate for years and I am very happy with it.
    Tuesday, July 22, 2008 4:26 PM
  • User1985809290 posted

    Both static classes and singletons come with a few risks that you should be aware of. The first is that of concurrency - since multiple clients (objects) will be simultaneously using the same static class (or singleton). For e.g. - if you have a simple 'if' statement - e.g. if(localVariable == null) type of check inside your static method, you will need to provide a lock around the code to allow simultaneous access. You will need to lock every potential shared variable in your static class (or singleton).

     Secondly, if you use a static class (as opposed to a singleton), you lose the ability to maintain state - for e.g. - if your DAL needs to keep a counter for the number of open connections it is currently serving (this is a slightly far-fetched example - but it conveys the point) - a static class will not serve you well - you will need to use an instance class - even if it is a single instance (singleton).

     All in all - you will be better served using a Singleton class that does the same thing as your static class - with no loss in functionality -  and the ability to change it to multiple instances down the road if need be.

    I recently blogged on a related topic - though it wasn't 'DAL' specific - it applies to DALs as well.

    http://anujvarma.com/BlogEngine.net/post/2010/05/21/Singleton-in-C.aspx

    Wednesday, June 9, 2010 6:22 PM