使用Entity Framework 4和Repository Pattern的多层体系结构

Question

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

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

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

• Generic：Generic Repository如果需要分开

• DAL：包含上下文类和存储库的EDMX（实体模型）文件

• BLL：系统的业务逻辑

  - 实体

  - 服务

  - 等

• 用户界面：ASP.NET页面

问题：

1. 逻辑分离是否正确？

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

3. 您会为最佳项目组织推荐哪种存储库模式实现，并且易于使用？

4. 使用静态存储库更好吗？

由于

Answer 1

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

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

Answer 2

我的首选设置是：

• Project.Presentation（UI）
• Project.Application（将DTO暴露给使用者/用户界面并对域层执行命令的应用层）
• Project.Domain
  • 实体[与域逻辑]（订单，客户，......）
  • 域名服务（TransferService，CreditCardService ...）
  • 存储库接口（IOrderRepository，ICustomerRepository，...）
• Project.Repositories.EF（使用特定技术实现存储库接口的数据访问（OrderRepository，CustomerRepository）
• Project.Infrastructure（Cross cutting）