存储库/服务模式和数据一致性

在使用存储库和服务模式的应用程序中，如何确保始终调用服务层，而不是直接调用存储库？存储库/服务模式和数据一致性

例子：

class OrderRepository 
{ 
    void CreateOrder(Order o) 
    ... 
} 

class OrderService 
{ 
    void CreateOrder(Order o) 
    { 
     //make some business logic tests 
     ... 

     //call repository 
     _orderRepository.CreateOrder(o); 
    } 
}

我看到两个问题：

程序员可以调用库直接，因为它不知道服务是否存在等（有时它不是那么简单在这个例子中（1个服务= 1个存储库具有相同的方法名称），一些应用程序没有很好的记录，或者有人急于忘记检查相应的服务是否存在（错误））。
完全不同：很久以前，有人创建了一些视图+直接使用订单仓库的控制器。那时不需要进行业务逻辑检查或额外的操作，只需要订单存储库（因为它根本不需要）。如果以后，在创建订单时需要一些额外的操作，将创建一项服务。问题在于所有进行旧存储库调用的控制器都需要更改。存储库原理/想法（以及分层代码）是否应该使部件彼此独立？

来源

2012-04-26 tigrou

“......应该让零件相互独立吗？”这是一个误解。它旨在使*责任*彼此独立。 'OrderRepository'仍然负责从数据库中提取数据并将数据保存到数据库，'OrderService'用于应用管理订单的逻辑。尝试通过改进方法名称来使这些责任更加清晰。 “SaveOrder”而不是'CreateOrder'代替'OrderRepository'是一种方法。换句话说： – 2012-04-26 20:32:44

您可以构建您的解决方案，以便所有存储库和服务都在各自的项目中，例如， Repositories和Services。

应引用Repositories的唯一项目将是Services。这样，其他项目将无法访问存储库。当然，没有什么可阻止开发人员将存储库项目包含到控制器项目中，但希望在这一点上他们会问自己为什么不包括在首位。

来源

2012-04-26 19:47:30 Lester

：这是否意味着我将不得不从一开始就为每个可能的存储库创建一个服务（以及其中的每个方法）？如果我有很多存储库和方法，它会需要巨大的努力来创建和维护？（或者我不明白你的建议） – tigrou 2012-04-26 19:54:58

这可能是我不明白你的问题。我所描述的是，如果存储库永远不会被直接调用，那么总是有一个服务会调用一个（或多个）存储库。如果可以直接调用某些存储库，则这不起作用。至于努力，如果你只是想公开一个简单的存储库方法，那么涉及更多的管道工作，但我觉得值得。 – Lester 2012-04-26 20:00:05

Static analysis工具可以在这方面提供帮助。

nDepend是一个商业工具，可以集成到您的构建过程中，并在这种情况下出错（任何非服务类直接调用存储库类）。

来源

2012-04-26 19:38:34 Oded

存储库/服务模式和数据一致性

回答

相关问题