Communication between BLL and DAL

Question

Solution setup:

• DAL (class library)
• BLL (class library)
• Common (class library (some common functionality - enums, logging, exceptions,...))
• Application1 (Windows Application)
• Application2 (Windows Application)
• WebApp (Web application)
• ...

Let's say I have a Customer entity, which is:

• a table in SQL server
• a CustomerDataTable in DAL
• a Customer class in BLL
• a BLL.Customer class in all the applications

What kind of objects should BLL and DAL use for communication - DataTable or List<Customer> (for example)? In first case, BLL logic should transform Customer object to DataTable and send it to DAL. In secod case, DAL layer should be aware of Customer class, which is in BLL layer. But originaly DLL references DAL and not opposite...

Should I put all classes into seperate assembly, which is referenced by all others (Common, BusinessObjects, ...)? In this case I could use Customer class in all my projects.

Should I even bother to seperate DAL and BLL when I know, that only one BLL will use my DAL. In this case I could merge them together into one project.

PS - I am reading about DataTables and a lot of people say that we shouldn't use them at all. What are better options? Maybe it is time for me to learn some ORM mapping tools :)

Answer 1

In my opinion you should have another Layer (seperate dll). Like "domain", where would you keep all entities like Customer. Then simply include in all higher levels(DAL, BLL, UI and others) in hierarchy this assembly.

Sample architecture can look like this:

(Database) <-> DAL <-> BL <-> UI

and on all levels you will have access to "domain" layer. DAL should return List not a DataTable. On some stage your development process you may want to use in DAL some OMR like NHibernate with would also return a List, probably.

Answer 2

it's hard to answer this general question without knowing the application domain well enough. I would start with thinking about where future changes are most likely and try to figure out from that where flexibility is required.

my following thought are just a suggestion. feel free to consider them and change/ignore what you feel is irrelevant.

separating the DAL from the BLL is almost always a good idea. the data scheme is one thing that should be encapsulated and hidden from the rest of the application, so leave your DataTables, DataSets, ORMs or any other solution hidden in the DAL. the BLL (and layers above it) should use simple data types (meaning simple classes). I think it would be a good idea to put those classes in a Model class library that has no references and can be used everywhere.

it feels like you have a bit too much layering...do you really need a Customer class in the BLL and another one in the Application layer? could be, but I would make sure and think it twice over.

from my experience in one of my recent project (a weather web site with 200K unique visitors daily), we used link2sql for data access (mostly read only data), and simple data classes all over our ASP.Net MVC application (of course as part of models/view models). it worked quite smoothly, and we could easily change the data scheme without breaking down other layers.

as for your last question about DataTables, these objects, should you decide to use them (I would vote against), belong solely in your DAL. they should not be exposed to other layers as that would create coupling to that specific class. what if tomorrow MS invents a much better class? would you switch over now that you have a gazillion references all over your projects to the DataTables, its method and properties? would be nicer to just change your DAL to work with the NewAwsomeDataTable class and the rest of your app is blissfully ignorant.

hope that helped :)