如果我以后要应用ado实体框架，推荐的数据访问层设计模式是什么？

我正在创建一个网站并使用 Linq to SQl 作为数据访问层，并且我愿意使该网站可以在 linq to sql 和 ado 实体框架上工作，而无需更改其他层中的许多内容：业务逻辑层或 UI层，

实现这一目标的推荐模式是什么？你能简单解释一下如何做到这一点吗？

UPDATE

正如下面回答的那样，存储库模式将对我有很大帮助，

我检查了书呆子晚餐网站并理解它，但我在里面发现了这段代码：

public class DinnersController : Controller {

        IDinnerRepository dinnerRepository;

        //
        // Dependency Injection enabled constructors

        public DinnersController()
            : this(new DinnerRepository()) {
        }

        public DinnersController(IDinnerRepository repository) {
            dinnerRepository = repository;
        }

这意味着据我了解，它使用接口 IDinnerRepository 声明了一个dinnerRepository，并在构造函数中给了它dinnerRepository，在我的例子中，这将是 linq to sql 实现，

我的问题是，如果我需要切换到 ado.net 实体框架，我将需要编辑此构造函数行，或者有更好的解决方案吗？

Update 2

我应该将该存储库接口以及在我的解决方案中实现它的类放在哪里，数据访问层还是业务层？

The 存储库模式 https://web.archive.org/web/20110503184234/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx是一个不错的选择。如果将其实现为接口；那么您可以更改具体的类，而不必更改其他任何内容。

The 书呆子晚餐攻略 http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx有一个很好的存储库模式示例（带接口）。

您在那里列出的代码将进入您的控制器（如果您正在执行 MVC 应用程序）；你可以创建任何你想要的类，只要它实现了IDinnerRepository接口（或者你可以有类似的东西IRepository如果您想设计一个每个人都必须实现的接口来执行基本的 CRUD 操作，则可以实现特定的接口，如果您需要更多操作，则可以实现特定的接口（但我们不要对接口疯狂）。

如果您要对应用程序进行“分层”，那么该部分将位于“业务逻辑”层，而存储库将位于“数据访问层”。该构造函数合约将是“松散”耦合的部分。