Question

I have created a solution in Visual Studio to attempt to implement a basic 3-Tier C# Application. I’ve researched this concept and now I am trying to put it together using different projects for each Tier i.e I have projects for DataAccess, BusinessRules and BusinessObjects.

Should the BusinessRules project contain references to the DataAccess and BusinessObject projects? (And DataAccess and BusinessObjects should not reference BusinessRules?)

After setting this up, I realised although I understand what each layer is responsible for, I didn’t know if you should populate a Business Object(s) with data in the DataAccess layer, or whether the DataAccess Layer should pass the requested data to the BusinessRules and then populate the objects – what is the recommended way of doing this?

Answer 1

While it probably doesn’t help with your question, the answer will always be “It depends.” There is no “one ring to rule them all” when it comes to this. If there were, architects wouldn’t be needed.

That being said, in my particular case I like to:

• Have the Data Access layer operate on business objects. This assumes the DAL is all in code and not split between code and stored procs in a database.
• Have the Business Rules layer operate on business objects. Again assumes all code rather than stored procs.
• The Business Rules to Data Access is a tricky question. It depends heavily on the type of app and the rules. If you need your business rules to update the store, I’d probably extract interfaces from the DAL so that the business rules could depend only on the interfaces.

Again, those items work in my case. They could be completely wrong for you. Also, you didn’t mention a user interface layer, a service layer, a blah blah layer, etc. There can be a lot of pieces and parts.

There aren’t any hard rules that you must follow to be correct. You have to look at your needs, your requirements, and what constraints you have.

Good luck.