如果我稍后应用ado实体框架工作，推荐的数据访问层设计模式是什么？ [英] whats the recommended Data access layer design pattern if i will apply ado entity frame work later?

问题描述

我正在创建一个网站，并将Linq作为数据访问层使用，我愿意使网站能够同时处理linq到sql和ado实体框架，而不改变其他层面的许多事情：业务逻辑图层或UI图层，

实现此目标的建议模式是什么？你能简单地解释一下吗？

更新

下面的存储库模式将帮助我很多，

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

  public class DinnersController：Controller {
 
 IDinnerRepository dinnerRepository; 
 
 // 
 //依赖注入启用的构造函数
 
 public DinnersController（）
：this（new DinnerRepository（））{
} 
 
 public DinnersController（IDinnerRepository repository）{
 dinnerRepository = repository; 
} 
  

这意味着我知道它使用接口IDinnerRepository声明了一个dinnerRepository，在构造函数中给了DinnerRepository，这将在我的例子中，例如linq到sql实现，

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

更新2

我应该把这个Respository Interface和实现它的类放在我的解决方案，数据访问层或业务层？

解决方案

存储库模式是一个不错的选择。如果你实现它作为一个接口;那么你可以改变具体的类，而不必改变其他任何东西。

Nerd Dinner walkthrough 是Repository模式（带界面）的一个很好的例子。 p>

您在控制器中列出的代码（如果您正在做一个MVC应用程序）;并且你创建任何你想要的类，只要它实现了 IDinnerRepository 接口（或者你可以有一些类似于 IRepository 界面，如果你想设计一个每个人都必须实现的界面，做了基本的CRUD操作，然后在需要更多的时候实现特定的界面（但是让我们不要去界面疯狂）。

如果您将应用程序分层，那么该部分将进入业务逻辑层，存储库将位于数据访问层中，该构造方的合同将是松散耦合的部分。

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?

解决方案

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.

这篇关于如果我稍后应用ado实体框架工作，推荐的数据访问层设计模式是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！