Which pattern to implement on Data access layer and on the business layer?

Question

Im creating a 4 layer project like this

• a Data Access Layer
• a Business Logic Layer
• A Domain Model with only POCO classes relating to my entities (via EF5)
• a website as the frontend

i have always until now mixed the DAL and the BLL together and referenced the DAL from the website directly. this time, i would like to have some real separation of concerns here and i want to create a DAL which is a real DAL and unit testable coupled with a BLL that is really persistence agnostic (you know, like the pros do it) Im planning on using EF5

I have read lot of sites like

• http://architects.dzone.com/articles/implementing-repository
• http://www.codeproject.com/Articles/37155/Implementing-Repository-Pattern-With-Entity-Framew
• http://www.codeguru.com/csharp/article.php/c19335/Guide-to-Implement-the-Factory-Pattern-in-C.htm
• http://geekswithblogs.net/cdpcodingblog/archive/2012/04/17/a-simple-pattern-to-separate-business-logic-from-data-access.aspx
• http://blogs.microsoft.co.il/blogs/gilf/archive/2008/05/03/abstract-factory-pattern.aspx
• http://www.dotnetrangers.net/2011/05/01/common-design-patterns-in-c-4-0-part2-abstract-factory-pattern/
• What is the correct way to use Unit of Work/Repositories within the business layer?
• Entity Framework and MVC create DbContext in business layer or data access layer

soo basically i know i´ll have to use the factory, the repository and unit of work patterns but i dont know what goes where and what is a simple (but clear enough example) i could follow

what i know is that i shouldnt reference the DAL on the website bt i really dont know how to make the bridge.

Is there any example of this with say, a Product and an Order table?

Answer 1

Build a Service Layer that the Presentation Layer (web app) references. Then in the Service Layer you have a reference to the BLL, EF5 Entities and DAL. The Service Layer can be just a Class Library (ASP.NET Web API for example) or a Web Services layer (WCF for example).

Now your web application has no hard reference to the DAL, but rather only knows of the Service Layer and the EF5 Entities.

Answer 2

I believe that you are searching for the onion architecture.

... the “core” of the onion is the object model, which represents your domain. This layer would contain your POCO entities. Surrounding your domain entities are repository interfaces, which are in turn surrounded by service interfaces. Representing your repositories and services as interfaces decouples consumers from concrete implementations, enabling you to swap one out for another without affecting consumers, such as client UI’s or tests. The data access layer is represented in the outer layer as a set of repository classes which implement the repository interfaces. Similarly the logging component implements a logging interface in the service interfaces layer.

(from here)

You should also consider exploring inversion of control/dependency injection. I adopted SimpleInjector (see here and here) a few months ago. The man behind SimpleInjector has some enlightening posts that will help you (starting with this one).

Answer 3

soo basically i know i´ll have to use the factory, the repository and unit of work patterns but i dont know what goes where and what is a simple (but clear enough example) i could follow

You say you know you'll have to use them but do you have a precise idea why you need each of them in the first place ? ;)

Aren't you taking the wrong approach trying to mimic how "the pros" do and throw all of these patterns at your system at once ? Maybe you could just start writing the simplest, most naive implementation that fulfills your requirements (testable DAL + persistence-ignorant BLL) based on more general principles.

Design patterns are only a means to an end. Chances are you'll feel the need for them while designing or trying to improve your implementation, but maybe it won't be the case.

As far as good general application architecture guidelines, I'd recommend Uncle Bob's work on Clean Architecture. I've found that even when he comes to describing specific software constructs with his own vocabulary, the way he explains them makes it easy for you to see them as placeholders - general concepts that you can later equate with Repositories, Unit of work and so on.