I have an architecture question. I have DAL project with poco classes (equivalent tables in database), BLL project and UI project. UI project has reference to BLL project and BL
Well, there is no single correct approach. But I tend to avoid creating set of DAL classes. Modern ORMs allow to work with POCO classes. Yes, there is some limitations (like enums) but IMHO it does not worth creating two copies of each business entity and mapping between them. So, I go with single POCO entity which sits in business logic assembly. Entity Framework works with that entity saves and loads it from database. No mapping.
Presentation layer is different. Usually you have several representations of same entity on different pages. You also would use different Data Annotation attributes to set restrictions on view models, or some UIHints. That would pollute your business entity with UI-specific logic. Also you will often need to display formatted or modified data, like FullName instead of FirstName and LastName of your Person entity. So, here I don't use my POCO business entities, and create view models instead.
With your product sample this approach will look like:
Product
Product
ProductViewModel
, BriefProductViewModel
etc. It's also responsible for mapping between Product
and view models. Note - manual mapping is time-consuming. I suggest you to use some mapping library, like AutoMapper or ValueInjecterYou should define you POCO (domain) objects in your BLL project, since they are business objects.
Your DAL should have a reference to the BLL, not the other way around.
Personally I am a follower of the Onion architecture which places your domain in the centre of your application. Any layer you add should only reference inward, not outward. So by that definition, your BLL is the centre, and is not referencing anything. Add a DAL layer, and it can only reference inwards, so it can reference the BLL. The UI layer is also only referencing the BLL, but not the DAL, since the DAL is an implementation detail.