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

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.