how to design Repository pattern to be easy switch to another ORM later?

Question

I am new to repository pattern but i tried, my goal is to make a design which will let me easily with just some few edits "dependency injection, or configuration edits" to be able to switch to another ORM without touching other solution layers.

I reached this implementation:

and here is the code:

public interface IRepository<T>
{
    T Get(int key);
    IQueryable<T> GetAll();
    void Save(T entity);
    T Update(T entity);
    // Common data will be added here
}
public interface ICustomerRepository : IRepository<Customer> 
{
    // Specific operations for the customers repository
}
public class CustomerRepository : ICustomerRepository
{
    #region ICustomerRepository Members

    public IQueryable<Customer> GetAll()
    {
        DataClasses1DataContext context = new DataClasses1DataContext();
        return from customer in context.Customers select customer;
    }

    #endregion

    #region IRepository<Customer> Members

    public Customer Get(int key)
    {
        throw new NotImplementedException();
    }

    public void Save(Customer entity)
    {
        throw new NotImplementedException();
    }

    public Customer Update(Customer entity)
    {
        throw new NotImplementedException();
    }

    #endregion
}

usage in my aspx page:

protected void Page_Load(object sender, EventArgs e)
    {
        IRepository<Customer> repository = new CustomerRepository();
        var customers = repository.GetAll();

        this.GridView1.DataSource = customers;
        this.GridView1.DataBind();
    }

As you saw in the previous code i am now using LINQ to sql, and as you see my code is tied to LINQ to sql, how to change this code design to achieve my goal "be able to change to another ORM easly, for example to ADO.net entity framework, or subsonic"

Please advice with simple sample code

Answer 1

Inc Wall o' Text

What you're doing is right, your code would be applied to each repository.

As you stated, the purpose of the Repository pattern is so you can interchange the way the data is delivered to your application without having to refactor your code in your application (UI/delivery layer).

Take for example, you decide to switch to Linq to Entities or ADO.NET.

All you would need is to write the code for the ORM you'll be using (having it inherit the proper Interface), then have your code use that repository. Of course you would need replace all references of the old repository or rename/replace your old ORM repositories so that your application uses the proper ones (Unless you're using some type of IoC container, in which you would specify which repository to pass).

The rest of your application would continue to run properly since all the methods you used to get/edit your data will return the proper objects.

In layman's term, the repositories will give your application the data it needs the same way. The only difference is how that data is retrieved from your database (ADO.NET/Linq to something etc.)

Having your classes inherit the Repository Interfaces is a hard-constraint making sure they output the data in a uniform fashion that agrees with the way your application uses it.