locked
Calling DAL from BLL RRS feed

  • Question

  • User269881539 posted

    Further to my other post I'm trying to move code to true UI > BLL > DAL model.

    I currently have I suppose a merged DAL and BLL in my setup - i.e. one class that represents for example a product, with fetch, insert, update etc methods.

    So my DAL should deal with the basic CRUD operations - i.e. the code that actually interacts with and executes the stored procedures in my DB for example.

    Then in the BLL how best to utilise this ?

    Do I have to create duplicate methods for the CRUD operations that just in turn call the ones in the DAL? So in my BLL I'll have an Update method for example that would take thhe values I have passed into the properties, and pass them through to the DAL, where the update is actually run. Do I then not have to mirror all of the properties in both DAL and BLL?

    Do I have to create the DAL class as an object within the BLL to utilise it?

    I have looked at TheBeerHouse example and whilst I can't see exactly whats what, are they importing DAL into BLL via namespaces - does that save instantiating as an object?

    Friday, September 9, 2011 9:26 AM

Answers

  • User-952121411 posted

    I have not worked with the BeerHouse starter kit so maybe someone that has can chime in about the specifics. However, it is not a requirement that the first class called in the DAL be the actual one that communicates with the database. If they refactored db communication that could be shared by multiple DAL classes into a single or few classes then this is perfectly acceptable and the preferred approach when the logic can be reused.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, September 12, 2011 9:15 AM

All replies

  • User-952121411 posted

    Do I have to create duplicate methods for the CRUD operations that just in turn call the ones in the DAL?

    Sometimes in a this architecture's and application simplest of needs, you could answer 'Yes' to this question. The BLL could have methods that almost act as a proxy passing the data down another layer to the DAL. In fact in one of the early 3 layer MSDN examples even quotes this fact:

    "The methods that simply return data – <tt xmlns:asp="http://msdn.microsoft.com/asp">GetProducts</tt>, <tt xmlns:asp="http://msdn.microsoft.com/asp">GetProductByProductID</tt>, <tt xmlns:asp="http://msdn.microsoft.com/asp">GetProductsByCategoryID</tt>, and <tt xmlns:asp="http://msdn.microsoft.com/asp">GetProductBySuppliersID</tt> – are fairly straightforward as they simply call down into the DAL. While in some scenarios there may be business rules that need to be implemented at this level (such as authorization rules based on the currently logged on user or the role to which the user belongs), we'll simply leave these methods as-is. For these methods, then, the BLL serves merely as a proxy through which the presentation layer accesses the underlying data from the Data Access Layer."

    http://msdn.microsoft.com/en-us/library/aa581780.aspx

    Now the part of that quote that sticks out is what the BLL potentially can do. This is to filter the actual business rules of your application before passing the data downstream or upstream; that is the role of the BLL. What if you were not allowed to do an 'Insert' on a product order for example unless the product was actually in stock? This rule could be validated in the BLL.

    Do I then not have to mirror all of the properties in both DAL and BLL?

    Well you could pass the individual properties each as an individual parameter, but this gets out of hand quickly for classes that have a lot of properties. The preferred 'next step method' (for beginners) is to pass the object instance to the next layer. This way only a single parameter is required rather than say 30 different individual properties.

    Public Sub DoSomething(OrderData As Order, ShippingData As Shipment)
        'Example method of passing in 2 instances: Order and Shipment
    End Sub
    

     

    Friday, September 9, 2011 9:43 AM
  • User269881539 posted

    In TheBeerHouse example they seem to have split the DAL - for example for Products I can see ProductDetails.vb in the DAL folder but with no communication to the DB. That all seems to be in the SQLClient\SQLStoreProvider.vb class, with a further BLL class as Store\Product.vb.

    In this instance do you think this is just to hold all DB code together, and the DAL code is to provide an object to be returned as a collection?

    Friday, September 9, 2011 12:18 PM
  • User-952121411 posted

    I have not worked with the BeerHouse starter kit so maybe someone that has can chime in about the specifics. However, it is not a requirement that the first class called in the DAL be the actual one that communicates with the database. If they refactored db communication that could be shared by multiple DAL classes into a single or few classes then this is perfectly acceptable and the preferred approach when the logic can be reused.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, September 12, 2011 9:15 AM