0

我正在使用实体框架（POCO 实体）设计分层架构（所有层都在同一台机器上），以便将相同的层与 ASP.Net MVC 应用程序、移动应用程序等一起使用；也为了保持可测试性......

我将拥有 UI 层 > 服务层 > 存储库层 > 实体框架 > 数据库，具有依赖注入、层抽象和关注点分离。

  • 假设，我有两个方法（客户，订单是实体类）。我应该在哪一层放置这些方法？：

    • 包含 LINQ 查询的公共 IList GetOrdersByCustomerId(int CustomerId)。
      （存储层，还是服务层？）
    • public void RequestAnOrderAndStartTheShipmentProcess(Customer CustomerEntity, Order OrderEntity) 执行一些插入操作，如 orderRepository.Add(OrderEntity)、shipmentRepository.Add(ShipmentEntity) 等...
      （单独的业务逻辑层或服务层？）

  • 我将有 IOrderService 接口，以及用于依赖注入的“OrderService : IOrderService”类，接口和类将定位在同一个程序集中，还是应该定位在不同的程序集中？

谢谢

编辑

感谢您的回答。但是在这种情况下，想到了四个问题...
1.如果UI有引用DataAccess程序集，开发人员可以直接在UI代码中访问DataAccess类，难道不应该增加额外的代码审查工作吗？ （例如，如果团队中有初级开发人员）？
2.我明白了，我应该在Repository层（做真正的查询）和Service层（在OrderRepository类中调用GetOrdersByCustomerId方法）都有GetOrdersByCustomerId方法，对吗？
3. 另外我应该对（几乎）所有表进行 CRUD 操作以维护它们，并考​​虑我当前项目中有 96 个表（不是太多但也不少），我应该有添加、更新、删除方法也在服务层？还是我应该在我的服务层考虑更多的“行为”？
4. 我很困惑，如果我的 OrderRepository 中有 GetOrdersByCustomerById、GetOrdersByStatus 等方法，那不就是一个 DAO 类吗？

4

2 回答 2

2

您可以考虑具有三个组件（层）的架构：

包含您的服务类的业务
（以及您的 RequestAnOrderAndStartTheShipmentProcess 方法）。业务层将包含您所有的核心业务规则，因此您不太可能突然想用一个全新的层交换这个层或添加一个替代方案。因此，我会在此程序集中同时保留 OrderService 和 IOrderService。我还将 POCO 类（让 EF 像这样为你自动生成这些）和存储库接口放在这一层中。

DataAccess
这是您保存 EF 存储库实现（以及您的 GetOrdersByCustomerId 方法）的地方。该程序集引用了业务程序集，因为它实现了在该层中找到的存储库接口。

UI
在这里，您从 DataAccess 程序集中实例化存储库，并使用构造函数注入将它们注入到业务层的服务类中。因此，该程序集具有对 Business 和 DataAccess 的引用。

使用这种架构，您的业务层与其他层很好地分离，并且易于单元测试。有关依赖注入的更多详细信息，请参阅此答案。

于 2012-05-22T18:50:24.350 回答
1

我的意见（总是有点武断）：

  1. 存储库，因为它是对单个实体集的典型指定获取操作。
  2. 服务层，因为它在多个实体上编排了多个操作。
  3. 分离程序集，因此您可以从其他程序集中添加接口实现，而无需引用已包含实现的程序集。
于 2012-05-21T18:21:25.613 回答