Question

I am creating a website and using Linq to SQl as a data access layer, and i am willing to make the website can work on both linq to sql and ado entity framework, without changing many things in the other layers: business logic layer or UI layer,

Whats the recommended pattern to achieve this goal? can you explain in brief how to do that?

UPDATE

As answered below that repository pattern will help me a lot,

i checked nerd dinner website and understood it, 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;
        }

Which means as i understood that it declare a dinnerRepository using the interface IDinnerRepository , and in the constructor gave it the DinnerRepository, which will be in my case for example the linq to sql implementation,

My question is if i need to switch to ado.net entity framework, i will need to edit this constructor line or there is a better solution for this?

Update 2

Where should i put this Respository Interface and the classes which implement it in my solution, in the data access layer or in the business layer?

Answer 1

The Repository pattern is a good choice. If you implement it as an interface; then you can change out the concrete classes and not have to change anything else.

The Nerd Dinner walkthrough has an excellent example of the Repository pattern (with interface).

The code you listed there would go in your controller (if you were doing an MVC Application); and you create any class you wanted so long as it implemented the IDinnerRepository interface (or you could have something like an IRepository interface if you wanted to design an interface that everyone had to implement that did the basic CRUD actions, and then implement specific interfaces if you needed more (but let’s not go interface crazy).

If you’re ‘tiering’ your application, then that part would go in the “Business Logic” layer, and the Repository would be in the “Data Access Layer”. That constructor contract would be the ‘loosely’ coupled part.