2

我一直在阅读存储库模式并努力寻找关于人们如何处理返回的数据不仅仅是您的标准模型（即 NOT Customer 1..* Account）的情况的可靠答案

我正在构建一个分析系统，它返回聚合的数据，有时跨越许多表。此外，这些表中可能有数百万条记录正在连接中。简而言之，我的典型结果集不是我的核心领域模型，而是（有时是极端的）它们的跨度、排列和聚合。

过去，我只是简单地构建了我的查询并将结果作为自定义结果集返回（授予这允许从我的系统的上层访问 ORM，因此没有将我的系统与正在使用的 ORM 的知识分开） .

存储库模式在这里不合适吗？其他人是如何处理这种情况的？感觉有点像方钉/圆孔。

作为参考，我正在使用带有 MSSQL DB 的 ASP MVC 在 C# .Net 中进行开发。

更新

虽然我的方案主要基于报告，但我仍在处理构成报告所基于的数据的各个实体。

作为（只是）一个例子：我仍然需要我的Customer实体，而客户仍然需要Orders他们通过系统生成的实体。在这种情况下，我的域 POCOS 在这里运行良好。在收到 MANYOrders并且必须以与我现有域对象附近的任何地方都不匹配的格式报告它们以及它们的许多连接的聚合表后，问题就出现了。

4

1 回答 1

4

我认为存储库模式不适用于您的场景，尤其是分析数据。当您不仅需要查询而且还需要持久化时，存储库会带来最大的好处。此外，除了某些例外，存储库应该与聚合是一对一的，而不仅仅是任何实体或值对象。

在您的场景中，您没有理由不能只使用 SQL 查询数据并返回简单的只读对象。您仍然可以通过封装这些查询来获得存储库的一些好处，这样消费者就不需要直接调用 SQL。将它们公开为简单的服务调用。这通常适用于所有查询。

于 2013-04-04T01:31:55.290 回答