The relationship between BLL and DAL

Question

Solution customization:

• DAL (class library)
• BLL (class library)
• General (class library (some common functions - enumerations, logging, exceptions, ...))
• Appendix 1 (Windows Application)
• Application2 (Windows Application)
• WebApp (web application)
• ...

Let's say I have a Client object that:

• table on SQL server
• Client DataTable in DAL
• Customer class in BLL
• class BLL.Customer in all applications

Which objects should use BLL and DAL for communication - DataTable or List<Customer> (for example)? In the first case, the BLL logic must convert the Customer object to a DataTable and send it to the DAL. In the case of secod, the DAL layer must know the Customer class, which is in the BLL layer. But the original DLL refers to DAL and not the opposite ...

Should I put all the classes in a separate assembly referenced by all the others (Common, BusinessObjects, ...)? In this case, I could use the Customer class in all my projects.

Do I even have to reflect on DAL and BLL when I know that only one BLL will use my DAL. In this case, I could combine them into one project.

PS - I read about DataTables, and many say that we should not use them at all. Which options are better? Maybe it’s time for me to learn some ORM mapping tools :)

Answer 1

In my opinion, you should have another layer (separate dll). As a "domain", wherever you save all entities, such as the Client. Then simply include in all higher levels (DAL, BLL, UI and others) in the hierarchy of this assembly.

An example architecture might look like this:

(Database) ↔ DAL ↔ BL ↔ UI

and at all levels you will have access to the "domain" layer. DAL should return a List, not a DataTable. At some point, your development process, which you might want to use in DAL, can be, for example, using OMR, such as NHibernate, with a list return.

Answer 2

It is difficult to answer this general question without knowing the application area well enough. I would start by thinking about where future changes are likely, and try to figure out where flexibility is needed.

my next thought is just a suggestion. Feel free to review them and change / ignore what you consider insignificant.

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

it looks like you have too many layers ... do you really need the Customer class in the BLL and one more at the application level? maybe, but I would make sure and think twice.

in my experience in one of my recent projects (a weather website with 200,000 unique visitors per day), we used link2sql to access data (mostly read-only) and simple data classes throughout our ASP.Net MVC application ( Of course, as part of the viewing models / models). it worked quite smoothly, and we could easily change the data scheme without destroying the other layers.

as for your last question about DataTables, these objects, if you decide to use them (I would vote against), belong exclusively to your DAL. they should not be exposed to other layers, as this will create a connection with this particular class. What if MS invents a much better class tomorrow? switch now that you have a gazillion links for all your projects in DataTables, its method and properties? it would be better to just change your DAL to work with the NewAwsomeDataTable class, and the rest of your application will be blissfully ignorant.

hope this helped :)

Answer 3

I would use the following template as it allows you to switch to a different saving strategy later.

 UI/Consumer <--- (view models) --> BLL <--- Models ----> DAL/Persistence 

Here, View models are consumed outside of the BLL, and models are transferred through the BLL / DAL layers.

In your case, the model may be what uses DAL - DataTables, for example, or perhaps ORM objects. BLL is responsible for matching the model and the presentation model.

As for the preservation of types in their own assemblies - yes for view models and to maintain consistency, and for models.

Saving models and viewing models limits the leakage of conservation strategies outside of the BLL and thus allows future design changes to be consistent.

One of the advantages of this separation is that consumers of different models can have different viewing models for the same stability model / object. Some of them can be small and have several attributes, while others are large and rich in functionality. It also allows you to enter offline / offline features, as view models can be returned at different points in time, which allows you to decide data merging strategies. It also allows you to create resilience objects (like tables for growth and shape change). Since it looks like a .net implementation such as AutoMapper , you get a lot of functionality out of the box

Of course, this may be too redundant for your application, but I still support BLL mapping, which will only consider viewing models for all BLL consumers. This should give you enough denouement.

Answer 4

Clicking domain objects in dal is an option that removes the crcular dependency, but may not match your intent. However, this is not unheard of; for example, LINQ-to-SQL related objects will live in DAL.

Other parameters:

• put them in a common bottom assembly (but this may leave your BL pretty empty)
• use IOC to remove / cancel link between BL / DAL

There is not a single correct answer.

Re DataTable I personally agree - I'm not a fan;) However, they can be used successfully and wisely. But if I had to use them, I would save them in the DAL as an implementation detail - and not disclose them above that.