Communication between BLL and DAL

Question

Solution setup:

• DAL (class library)
• BLL (class library)
• Common (class library (some common functionality - enums, logging, exceptions,...))

Answer 1

I would use the following pattern as it allows you to upgrade to a different persistence strategy later.

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

Here the View models are consumed outside the BLL and models are communicated across the BLL/DAL layers.

In your case the model can be anything the DAL uses - DataTables for example or later perhaps ORM entities. The BLL is responsible to mapping between the model and view model.

As to keeping types in their own assemblies - yes for view models and in order to maintain a consistency, yes for the models as well.

Keeping the models and view models separate stops leakage of the persistence strategies outside of the BLL and thus permits future design changes to the persistence.

One advantage of this separation is that that different view model consumers can have differing view models for the same persistence model/entity. Some could be small and have few attributes and others large and rich in functionality. It also permits you to introduce offline/disconnectedness capability as the view models could be returned at differing times allowing you decide data merging strategies. This also allows you're persistence entities (e.g. tables to grow and change shape). Since this looks like a .net implementation things like AutoMapper will provide a lot of functionality out of the box

Of course this may be way overkill for your app - however I'd still maintain a BLL mapping that only talks view models to all BLL consumers. This should give you enough decoupling.