Question

我是存储库和分层应用程序的初学者，我不明白哪些是存储库和业务层类之间的交互和关系

以下是3层购买订单的示例，我想查看是否正确以及您的更正

for DataAcesslayer

存储库OrderRepositolry

    Namespece Dal
    {
       Public class RepositoryOrder
       {
              POrderContext context = new POrderContext ();
 
              Public IEnumrebale <Order> GetAll ()
              {
                   Context.Orders;
              }
// Following code
       }
    }

对于订单存储库代码项：

namespece Dal
{
      public class RepositoryOrderItem
      {
             POrderContext context = new POrderContext();

             public IEnumrebale<OrderItem> GetAllItemById(Order o)
             {
                  context.OrderItems.where(i => i.OrderId == o.Id);
             }

            public OrderItem GetItemById(int id)
            {
                 context.OrderItems.Find(id);
            }
//Following code
      }
}

对于businessLayer，这里是classOrderBLL代码：

namespace BLL
{
      public class OrderBLL
      {
            RepositoryOrder repoOrder = new RepositoryOrder();
            RepositoryOrderItem repoItem = new  RepositoryOrderItem();

            public IList<Order> GetAll()
           {
               return repoOrder.GetAll();
           }

            public decimal GetPrixTotal(Order order)
           {
                var query = from item in repoItem.GetAllItemById(order)
                                 select sum(item=>item.Prix * item.Quantite);
                return query;
            }
      }  
}

总价格计算是否在存储库级别完成或者在BLL级别（我们可以使用上下文来生成此请求linq 在存储库中）？
CRUD方法在存储库中完成，它们在BLL中被调用存储库是对的吗？
linq中的where方法对应逻辑业务或
存储库（数据访问层），因为它确定了某些规则生意？

Answer 1

我确信这个问题会被归结为“主要基于意见”但在此之前我会跳出来给出“主要基于意见”的答案： - ）

对数据库应用程序进行分区有两种方法，它们取决于它的复杂程度和大小。实体框架示例倾向于提供一个非常简单的模型，其中EF Data类向Business层公开，然后将它们公开给View Model或其他层。对于简单的应用程序而言，这可能是正确的，但对于更复杂的应用程序，以及数据存储方法不是RDBMS（即No-SQL）或者您希望在业务和存储库数据结构之间创建分离的应用程序，它太简单了。

存储库层应该有一组类，用于描述如何从存储库访问数据。如果您有一个RDBMS，这些可能是EF POCO类，但如果您有一个Web服务端点作为您的存储库，则可能是SOAP文档，REST结构或其他数据传输对象。对于像SQL Server这样使用专门存储过程来访问其数据的RDMBS，Repository层可能只是一组镜像命名和参数以及存储过程返回的数据集的类。请注意，由RDBMS以外的任何内容返回的数据结构可能不一致 - 即，由存储库中的一个方法调用返回的“客户”概念可能是与不同调用返回的“客户”不同的数据结构。在这种情况下，存储库类不适合EF。

转移到业务对象层 - 这是使用数据类，验证类和流程类模型创建业务域模型的位置。例如，用于记录销售订单的Process类可以组合业务客户，业务销售订单，业务产品目录数据概念，并绑定许多验证类以形成单个原子业务流程。这些类可能（如果您正在执行非常轻量级的应用程序）类似于Repository层的数据，但它们应该单独定义。在此图层中，您可以保存计算的概念，例如“销售订单总额”或“增值税计算”或“运费”。它们可能会或可能不会存储到您的存储库中，但它们的含义定义是在业务层中建模的。

业务层提供将数据复制到View Model中的类。这些类可以与存储库类非常相似（并且在最简单的情况下，相同），但是他们的工作是模拟用户界面和用户交互。它们可能只包含业务数据类中的一些数据，具体取决于UI的要求。这些类应该执行基于用户界面的验证，它们可以委托给业务层，或者可以添加额外的验证。这些类的工作是管理作为用户界面的状态机。

我的总结是，在大型系统中，你有三组课程;数据存储库交互，业务模型交互和用户界面交互。只有在最简单的系统中，它们才被建模为一组物理POCO类。

数据数据访问层与业务层之间的交互

1 个答案: