服务层，存储库层和实体框架

Question

我正在使用Entity Framework（POCO实体）设计分层架构（所有层都在同一台机器上），与ASP.Net MVC应用程序，移动应用程序等使用相同的层;还要保持可测试性......

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

• 假设我有两种方法（Customer，Order是实体类）。我应该将这些方法放在哪一层？：

  • 包含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 Layer（在OrderRepository类中调用GetOrdersByCustomerId方法）中使用GetOrdersByCustomerId方法，是否正确？
 3.此外，我应该为（几乎）所有表进行CRUD操作来维护它们，并考​​虑我当前项目中有96个表（它不是太多，但也不是很少），我应该有Add，Update，Delete方法吗？在服务层呢？或者我应该在服务层中考虑更多“行为”？  我很困惑，如果我有GetOrdersByCustomerById，     我的OrderRepository中的GetOrdersByStatus等等方法不是     像DAO一样？

Answer 1

您可以考虑一个具有三个程序集（层）的架构：

业务
包含您的服务类（以及您的RequestAnOrderAndStartTheShipmentProcess方法）。业务层将包含您的所有核心业务规则，因此您不太可能突然想要将此层与完整的新层交换出来或添加备用层。因此，我会在此程序集中保留OrderService和IOrderService。我还会在这一层中放置POCO类（让EF为你自动生成这些类似this）和存储库接口。

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

用户界面
在这里，您从DataAccess程序集中实例化存储库，并使用构造函数注入将这些存储库注入到Business层的服务类中。因此，此程序集引用了Business和DataAccess。

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

Answer 2

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

1. 存储库，因为它是单个实体集上的典型指定get操作。
2. 服务层，因为它在多个实体上协调多个操作。
3. 单独的程序集，因此您可以从其他程序集添加接口实现，而无需引用已包含实现的程序集。