Design of Business Layer

Question

Hi, We are currently revamping our architecture and design of application. We have just completed design of Data Access Layer which is generic in the sense that it works using XML and reflection to persist data.

Any ways now we are in the phase of designing business layer. We have read some books related to Enterprise Architecture and Design so we have found that there are few patterns that can be applied on business layer. Table Pattern and Domain Model are example of such patterns. Also we have found Domain Driven Design as well.

Earlier we decided to build Entities against table objects. But we found that there is difference in Entities and Value Objects when it comes to DDD. For those of you who have gone through such design. Please guide me related to pattern, practice and sample.

Thank you in advance! Also please feel free to discuss if you didn't get any point of mine.

Answer 1

CSLA.NET works pretty well as a base for the business layer.

Answer 2

@Adil,

I'm not very experient user, anyway, this is the kind of model I'm using (also with NHibernate).

GUI - with all the web forms and so on BLL - The catalogs that are responsible for creating instances of new objects DAL - The place where classes responsible for interaction with NHibernate are implemented. The NHibernate mapping files are here.

Model - Class Library that is used by the BLL and DAL for data transfer object between.

Different patterns are used. For example, the BLL and DAL have a Factory class that allow access to an interface. The catalogs are Singleton classes. All of the catalogs are accessible using a master Singleton class representing my business logic top object (for example "Enterprise" => "Enterprise.PeopleCatalog".

Anyway, hope it helped...

@AngryHacker, thanks for the tip, could you give an example of CSLA.NET?

Answer 3

@Adil, this is not an answer to your original question, but I would advise you to revise your decision to roll your own data access layer. You note that you'd like to go to NHibernate: just do it now.

IMO, writing an ORM is a waste of time unless you have some very specific restrictions. There are a wealth of options out there, with hundreds of hours of effort poured into them already. Leverage it! LINQ2SQL, Entity framework, NHibernate, Subsonic, LLBLGen are all good, and there are more out there.

Note too that if you roll your own you won't get to use the goodness that is LINQ without a lot of effort.

As far as layering goes, try not to go nuts: keep the number of layers in check and concentrate instead on building a worthwhile interface between them to guard against your abstractions leaking.

I've seen a number of very "patterned", beautifully layered projects that in use end up with logic everywhere and persistence abstractions leaked all over the place. Keep it simple!