使用实体框架 4 和存储库模式的多层架构

Posted 2023-04-12

【中文标题】使用实体框架 4 和存储库模式的多层架构

【英文标题】：Multi layered architecture using Entity Framework 4 and Repository Pattern

【发布时间】：2011-10-12 19:19:05

【问题描述】：

我必须使用 Entity Framework 4.1 和 ASP.NET 构建 Web 应用程序的体系结构。我已经有了数据库结构，所以我必须使用database-fist。我在这里阅读了很多文章和主题，但似乎我错过了一些东西。我决定按以下方式组织项目：

我已经使用 Linq2Sql 构建了一个 Web 应用程序。我用this project。它提供了一个 T4 模板，为每个实体生成一个特定的静态存储库类。我喜欢这种方法，因为它很容易向任何存储库添加额外的逻辑，例如GetUserByName()。我喜欢这种方法，但到目前为止我找不到 EF4 的类似方法。我只找到了通用存储库，然后我必须手动创建具体的存储库。在这种情况下，我不喜欢首先我正在处理的应用程序具有一些复杂的业务逻辑，因此我必须为几乎每个实体手动创建具体的存储库。其次，如果一开始我使用通用存储库获取所有实体，后来我需要使用，例如GetUserByName()，那么代码中就会出现不一致的情况。我希望所有数据检索都以相同的方式完成。

我要么在架构结构中遗漏了一些东西。

Generic：Generic Repository（如果需要将其分开）

DAL：带有上下文类和存储库的 EDMX（实体模型）文件

BLL：系统的业务逻辑

-- 实体

-- 服务

--等等

用户界面：ASP.NET 页面

问题：

逻辑分离是否正确？

我应该使用特定的存储库吗？

对于最佳项目组织和易用性，您会推荐哪种存储库模式实现？

使用静态存储库更好吗？

谢谢

【问题讨论】：

拥有在 windows 和 web 中开发的重型金融系统的背景到目前为止我和你在一起，只是一点问题你认为你的实体应该住在 BLL 就我的经验而言，实体是非常基本的单位几乎每一层都飞来飞去。

那时我还没有做出最终决定。我也在考虑使用 EF 生成它们并将它们放入 DAL。

@Teddy - 这样的实体应该（可以）进入一个共同的“层”/组件，以便它们可以被重复使用；这些与特定于数据访问实现的 EF 实体不同。

【参考方案1】：

不要使用静态类作为存储库。对于正确的面向对象设计来说，这很糟糕而且很遥远。它还完全阻止了控制反转和依赖注入的任何可能性。

如果你想使用存储库模式，你必须使用特定的存储库。通用存储库只是 EF 相关类的包装器（其中 ObjectSet / DbSet 已经是 EF 相关的存储库）。您还应该在聚合根之上而不是在每个实体之上构建您的存储库。

【讨论】：

感谢您的建议。您知道生成特定存储库的方法吗？手动操作既费时又有点无聊。

【参考方案2】：

我的首选设置是：

Project.Presentation (UI) Project.Application（向消费者/UI 公开 DTO 并向域层执行命令的应用层） 项目.域 实体 [具有域逻辑]（订单、客户、...） 域服务（TransferService、CreditCardService...） 存储库接口（IOrderRepository、ICustomerRepository...） Project.Repositories.EF（使用特定技术实现存储库接口（OrderRepository、CustomerRepository）的数据访问） Project.Infrastructure（横切）