3-tiered web-service enabled architecture

Question

Dear All!

After reading tons of articles over the net about best-practise application-design and pattern I still cannot merge all the information together and map on my real-word-application...

I would like to have a 3-tiered application:

• UI-Layer:
  A silverlight-application hosted within an ASP.net - Webapp
  
  
• BusinessLogicLayer:
  WCF-Services / .NET RIA-Services running on a different Server
  
  
• DataAccessLayer:Using an ORM like nHibernate oder Linq2Entities

The problem is, I don't know where to put my business objects, and where to fill them with data.

Should there be an another layer, containing all my business objects, so they could be used in all other 3 layers?
Or should I place them into my BLL and call nHibernate-Methods in the DAL - but then I would have a circular dependency between BLL and DAL? Isn't it "over-architectured" if I introduce "DataAccessObjects" inside the DAL and just copy all the properties into the BusinessObjects in the BLL?

Any help appreciated!

Best regards, Daniel Lang

Answer 1

The business objects go in the Business layer. These objects are used by the UI layer, and call methods from the Data layer to populate themselves.

In general, objects in a layer only call methods in their own layer, or the one just below.

One of the motivations is to be able to replace one of the layers without changing the others. For example, there could be a different way to present the UI, which could use the same methods from the business layer. Or, perhaps the database could be changed, as long as the new data layer contains the same methods as the old one.

Answer 2

Well, because you're using WCF, you should have a "contract" that only contains interfaces and data classes. Those classes should be available to everyone else. No logic should be contained inside it.

Answer 3

Well, after reviewing the whole problem, I think the "best" solution is to use DependencyInjection or IversionOfControl to fill the business-objects with data in the DAL.