What is the recommended data access layer design pattern if I apply the ado entity framework later?
I am creating a website and using Linq to SQl as a data access layer and I am ready to make the site possible to work with both linq in sql and ado entity framework without changing much in other layers: business logic layer or user interface layer,
What is the recommended model for achieving this goal? can you briefly explain how to do this?
UPDATE
As mentioned below, the repository template will help me a lot,
i checked the dining room website and figured it out, but i found this code inside:
public class DinnersController : Controller {
IDinnerRepository dinnerRepository;
//
// Dependency Injection enabled constructors
public DinnersController()
: this(new DinnerRepository()) {
}
public DinnersController(IDinnerRepository repository) {
dinnerRepository = repository;
}
This means that I figured out that it was declaring a dining repository using the IDinnerRepository interface and in the constructor gave it a DinnerRepository, which would be in my case, for example a linq to sql implementation.
My question is if I need to switch to ado.net framework, will I need to edit this constructor line or is there a better solution for this?
Update 2
Where should I place this repository interface and the classes that implement it in my solution, in the data access layer or in the business layer?
source to share
the repository pattern is a good choice. If you implement it as an interface; then you can change specific classes and not change anything.
Walkthrough Nerd Dinner has a great example of a repository pattern (with an interface).
The code you put in there will be included in your controller (if you were making an MVC app); and you create whatever class you need as long as it implements the interface IDinnerRepository
(or you could have something like an interface IRepository
if you wanted to create an interface that everyone had to implement by doing basic CRUD actions and then implement certain interfaces. if you need more (but don't stop working crazy).
If you "overlay" your application, this part will go at the "Business Logic" level, and the repository will be at the "Data Access Layer". This constructor contract will be the "loosely coupled" part.
source to share
I ended up using a minor variation in the Repository pattern. I took it from the excellent Nerd Dinner tutorial. You can find the entire tutorial here and code is on Codeplex .
Don't let all MVCs turn you off if you are not in an MVC situation, Linq2SQL's basic encapsulation is good. In a recent codebase update, I moved from Linq2SQL to Linkq2EF and all changes were handled well in the repository, external code shouldn't have been touched.
It's also worth noting that the RIA Services stuff has a similar pattern. You point it to Linq2Sql or Linq2EF and it creates a base layer for you on top of it with CRUD. This layer is in the source code, so you can just rip it and use it in a non-RIA project, but I just leave it as it is and refer to it in other projects, so I use this layer even though I ignore the excessive wire of the ability.
source to share