asp.net-mvc - MVC 存储库模式设计决策

Question

我有一个 asp .net MVC 应用程序，最近开始使用服务验证层实现存储库模式，很像 this .

我一直在为我创建的每个模型创建一个存储库/服务。这是矫枉过正吗？相反，我应该为每个为许多不同模型提供 CRUD 的逻辑业务领域创建一个存储库/服务吗？

对我来说，似乎我要么用许多文件弄乱了项目树，要么用许多方法弄乱了一个类。 6 一种方式，另一种方式半打。你能想到任何好的论据吗？

Answer 1

通常，如果您使用的是“真正的”存储库模式，而不是其他持久层(例如 ActiveRecord 或 DAO)，您应该旨在识别您的域聚合，并为每个聚合创建一个存储库。

这意味着什么？好吧，这在很大程度上取决于您的应用程序，但通常有些对象自然是其他对象的“ parent ”，或者是相关事务的一部分。

我认为典型的例子是一个电子商务系统，其中你有一个订单的概念，在一个订单中你有订单线，每个订单线是一些产品和数量，等等。

在这种情况下，Order 对象是系统的聚合根之一，并且创建了一个 OrderRepository。

在这种情况下要记住的是，订单与其订单线等之间存在某种关系(暗示或其他)。因此，存储库上“CRUD”的 C-UD 部分通常应该只有一个方法，并且通常应该只接受该聚合根对象的一个​​实例并对其进行操作(例如 repo.Save(order))。可能还有其他可能的参数，但这取决于您的 impl。

实际上，您通常可以通过继承来解决大部分 C-UD 部分(即，使用一些已知的逻辑来实现它们的 RepositoryBase，以了解您的特定持久性方案应该发生什么)。

所以这给我们留下了 CRUD 的 R 部分。在这种情况下，如果您选择使用查询方法路线，您可能会获得大量查询方法(GetById；GetByName；GetByCustomerName 等)。有些人更喜欢，特别是对于简单的应用程序，公开一个基于 linq 的接口(interface)(例如，一个 IQueryable GetAll())，然后可以应用 Where 子句。 YMMV 取决于您对该应用的潜在持久性，但对于简单的应用程序来说，它是一个可靠的选择，尤其是。如果您希望您的持久性提供程序直接支持 linq。

最后，许多人实际上通过一种或另一种命令查询职责分离模式的实现来分离查询部分，该模式表示持久化和查询的接口(interface)应该不同。在这种情况下，您将拥有一个仅包含基本 CRUD(GetById、GetAll、Save、Delete)操作的 Repo 和另一类根据您的应用程序的意图查询事物的类。

希望有帮助。

保罗