N层应用程序混淆中的实体框架

Question

我正在构建一个相当大的(web)应用程序，在其中我使用实体框架与数据库进行通信。

我的解决方案按如下所示的层次设置：

• 客户端
  • 网站(MVC web应用程序)

• 服务器
  • BusinessLogic (包含业务逻辑。这个项目涉及很多业务规则)
  • 存储库(包含用于使用EF查询数据库的存储库类)
  • 接口(用于定义存储库类的接口，即IFirmRepository)
  • 模型(包含我的edmx文件、视图模型、枚举等)

因此，客户机/UI知道业务逻辑层，其中给定视图所需的业务类被注入到MVC控制器中。业务逻辑层了解接口和模型，存储库实现接口。

在过去的一周里，我一直在使用这种方法进行开发，我有一种感觉，它并不完全“正确”，因为：

1. 存储库类会因许多方法而变得臃肿，在这些方法中，我需要使用Include()方法来处理业务逻辑层中断开连接的实体。
2. 对于每个查询，我都使用一个新的上下文：using(var ctx = new MyContext())和单个业务逻辑方法可能会调用多个存储库方法，从而生成N个不理想的新MyContext()。
3. 关于上面的内容:我读到过每一个http请求都有一个上下文，当涉及到网站时，我的方法似乎“违反”了？
4. 出于好奇，我试图在业务逻辑类中直接使用MyContext，使所需的对象(S)查询，然后执行业务逻辑。这样做感觉非常顺利/容易，使存储库看起来比所需的工作量大得多，而且几乎是多余的。

因此，当涉及到架构时，我想不同的项目需要不同的方法，但是在我完全抓取我的存储库并在我的业务逻辑类中直接使用实体框架上下文之前，我希望您对此有自己的看法。抓取存储库感觉有点不对(从某种意义上说，我违反了某些东西)，但另一方面，不首先在接口中定义方法，然后将其实现为存储库，然后在业务逻辑类中使用它，就很容易做到这一点。

那么，你对此有什么看法？:-)我是完全不被记录在案，还是？

提前谢谢。

Answer 1

继续编写存储库。如果您使用的是实体框架，则不需要它。这只是一个毫无意义的抽象层。我建议采用服务/提供者模式。创建一个接口，该接口列出应用程序可以利用的API。界面将是您在web应用程序中直接使用的唯一工具。您将在具体的实现中使用依赖项注入。

就这一点而言，您将希望创建一个或多个实现此接口的类，但每个离散访问方法只创建一个类，即实体框架。例如，如果您想使用Web，则可能会有另一个。这个实现应该是泛型的，但是与其让整个类接受一个类型参数，相反，您将希望单个方法实现是泛型的。这允许您实例化一个可以处理整个上下文和它包含的任何实体的实例。

您的实体也应该实现接口，以便您的服务实现可以重用代码。例如，您可以不使用GetPublishedFoos和GetPublishedBars，而只需使用GetPublished<TEntity>，其中有TEntity : IPublishable。如果您在如何设置接口方面很聪明，那么您的服务将不需要大量的方法。

Answer 2

听起来你有太多的存储库了。

一般情况下，我会尽量坚持每个数据库一个。毕竟，这是您的底层存储库和它中的表(对象)都应该是相关的。因此，我可以期待查询/方法、lile、getFirmsWithCustomer等。

我认为，当您有一个大型应用程序时，您正在采取正确的方法将EF与业务逻辑分离开来。

我会进一步说，不要在这个模式下使用EF。EF最适用于您希望跳过编写数据层的小型项目。如果您一直使用Sprocs和存储库，那么使用SQL客户端编写代码就会越来越少和更容易。

Answer 3

我认为您的问题类似于是否在实体框架上使用存储库模式，我最近也在研究这个问题。这是我找到的一个链接，给出了很好的答案。

实体框架DBContext类已经实现了存储库模式。现在，如果我们抽象实体框架本身取决于，这个提供者(EF)本身是否会改变为类似web服务、xml等。在其他情况下，最好不使用自定义存储库类。