Business Logic Layer - How to implement? 2

[keyser456]

I've finally finished my Data Access Layer using a custom code generator that also creates the stored procedures the code will use to access the underlying data in my MS SQL Server database and. As tempting as it is to just use the DAL directly, I've read you should use a Business Logic Layer to communicate with the DAL. While there is a wealth of information on the net about creating DALs I haven't been able to find much info on business logic layers. I have a few questions.

Suppose I'm trying to retrieve a customer's information. I have a customer table and relationships to the sales order, sales invoices, and contacts tables (just to name a few). The DAL can get one record from a specific table using the primary ID # (customers_Record.GetRecord(inIDNumber)) and I also wrote it to allow me to retrieve related records in linked tables (customers_Record.Getsalesorders() - like the three listed above). In the BLL should I retrieve all the related sales orders, sales invoices, contacts, etc., or should that be independent of the business logic layer and the presentation layer will retrieve that information? If it shouldn't be part of the BLL, what exactly should be in the BLL? Thanks in advance. I hope I was clear enough with my question.

 

[stevexff]

keyser456

You are right, you have to know when to stop! You can retrieve records in other tables if it makes sense to do so. For example, say that an order contains a number of order details. The order details can't really exist in isolation, so you should bring them back with the order.

But should you bring back all the invoices for a customer? Probably not - there could be hundreds of them. Bring back a lightweight list of summarised invoices, and allow the user to select one. Defer instantiation of the invoice business object (with its invoice lines) until you know which one the user wants.

We can go a bit further with Lazy Load [Fowler], and defer the creation of the list(s) until it is actually requested. So we load the customer business object, and populate some common details like address and contact details. Set private booleans in the class to show that invoiceList, orderList, etc. have not been populated yet. If the client asks for the list, it can be retrieved by your data layer, and the private boolean set to show that the list is now available. But if they don't ask for it, you have avoided a whole load of unnecessary database I/O...

Hope this helps

Steve

 

[keyser456]

Thanks Steve, those were helpful suggestions on ways to keep uneccessary database operations to a minimum. However, after researching the topic all day yesterday and this morning it looks as though I arranged my DAL improperly.

I think my source of confusion is the custom business objects. Mine are sort of built into the DAL which may not be the proper way to do this (I got carried away with the code generator). Does anyone have links to information on this topic (custom business objects and/or business logic layers) or can they recommend any books? Or maybe you can just explain the whole topic to me here. That would be fantastic. (grin)

 

[stevexff]

Generating your business objects looks attractive at first, but you run the risk of coupling the database too tightly with the business objects.

It's not a simple topic, as the answer to 'what is the correct solution?' is often 'it depends'. A couple of good books are Patterns of Enterprise Application Architecture, Fowler, Addison-Wesley 2003, and Core J2EE Patterns, Alur/Crupi/Malks, Prentice-Hall 2003. The second one is obviously aimed at J2EE, but most of the patterns make good design sense whatever your platform.

 

[keyser456]

Thanks for the book recommendations. After doing some research on them I think I'll be buying GOF's Design Patterns and possibly Fowler's Patterns of Enterprise Application Architecture as suggested.

Also, I found the following article to be very detailed and helpful (would it be wrong to give myself a star? j/k):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

 

[stevexff]

The GoF book is the daddy. Some of the patterns in it are low level (iterator, observer) and have been built into class libraries like Java and .NET already. But the rest are still as good as ever. The only down side to it is that because of its age, all examples are in C++ and the diagrams are OMG rather than UML. My copy says "28th printing: 2004", so you'd have thought that given its popularity, they could have updated it.

The PEAA is excellent because the patterns are at a slightly higher level. The Core J2EE one is good, even if you don't use Java, as the tier-specific bad practices and refactorings section (about 50 pages) is worth the price of the book on its own.

 

[oj75]

keyser--

What programming language are you using? If you're using C#, thers is an adapted version of the GoF Design Patterns book which I recently purchased, Design Patterns in C# by Metsker. Also, Beginning C# Objects has been a good tutorial for me as I have recently focused on learning OO design and modeling techniques.

oj

OJ
DB/.Net/CR Developer