views:

133

answers:

1

Hi all,

I was looking for some feedback on the current design.

Here is how it currently looks

  1. Web App (UI) References BLL Layer and BusinessEntities Layer
  2. BusinessEntites Layer - Contains Interfaces and Classes (with internal validations on the properties)
  3. BLL (references the BusinessEntities and DAL Layer) - Has mostly Managers for each of the Business Objects with methods like Create() Save() Delete().
  4. DAL (references BusinessEntities Layers) - Has DB commands that create/add/update Business Entities Objects.

I'm not quite sure about the naming conventions i used for the layers so if anyone has any better suggestions than i'll gladly adopt them.

Also i don't like the idea of the DAL referencing the BusinessEntities Layer, but how else am i going to return objects instead of Datasets/DataTables?

Thanks for any feedback.

+1  A: 

With respect to your needing to reference the business layer from the DAL, I would agree that this is probably not optimal -- lower tiers should not know about the ones above them, it reduces reusability and adds extra/potentially circular dependencies.

Have you considered having your business entities "fill themselves up" and do their own persistence operations using the DAL classes, rather than the DAL acting like a factory for them (as in your current design)? That way, your DAL would be a more direct representation of the database, and the business entities would contain the (business) logic needed to fill and persist themselves appropriately.

Also, the "BLL" layer you spec out doesn't really appear to me to contain business logic; it looks to me to be more of a persistence services layer for the entities.

So a variation of what you propose could be:

  1. Web/UI, referencing Business Entities
  2. BusinessEntities, contains interfaces and classes with business logic. References DataServices layer
  3. DataServices, contains classes that load, find and persist data. Can serve up "generic" structures containing the data (Data Transfer Objects) that can be produced, consumed and processed by Business Entities. References DAL.
  4. DAL, which simply provides classes that map to tables.

Depending on your requirements, I would consider merging your BusinessEntities and DataServices (BLL in your original design) into a single tier; the only reason I can think of to split them apart is if you are doing something like Silverlight where you need asynchronous data operations on client-side business entities.

Of course all of this is with an incomplete knowledge of your specific system requirements -- you will need to design what is best for your specific application. Good luck!

Guy Starbuck
Thanks Guy.I'm still having a hard time understanding how the DAL would pass back a class to the DataServices Layer without knowing anything about it. I'm obviously very new to this so maybe an example would help. If you have the time of course, but If not that's okay.
AlteredConcept
I see you asked a follow-up question, but to briefly reply, I would define DTOs in the DAL, and if I needed a data access service tier, I would expose its interfaces to the BusinessEntities as message contracts, independent of the DTOs. The DTOs just let you avoid passing ADO.NET objects.
Guy Starbuck
So would it look like the following: DAL has IAddressDTO, a AddressDTO, // Create Address Object with the DTO }
AlteredConcept
Sure. You could also define your DTOs in a "common" assembly that can be referenced throughout all tiers, so that they are available to each tier and can be passed between them.
Guy Starbuck