Last post Sep 12, 2011 09:15 AM by atconway
Sep 09, 2011 09:26 AM|chilluk|LINK
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?
Sep 09, 2011 09:43 AM|atconway|LINK
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 – GetProducts, GetProductByProductID,
GetProductsByCategoryID, and GetProductBySuppliersID – 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
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
Sep 09, 2011 12:18 PM|chilluk|LINK
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
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?
Sep 12, 2011 09:15 AM|atconway|LINK
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.