我一直在阅读 Professional ASP.NET MVC 1.0 书中的第 11 章（可测试设计模式）。在本章的示例中，数据访问被分为多个存储库：IOrderRepository、IProductRepository 等。这一切都有意义：单个数据类的单个存储库。
然而，当您考虑表之间的链接时，这对我来说有点不合理：一个订单包含许多产品。当 LINQ-to-SQL 创建 Order 类时，该订单类将具有一个 Products 集合，该集合枚举与该订单相关的所有产品。因此，通过使用这个集合，我们绕过了 ProductsRepository。
因此，在模拟时，我不仅要模拟 OrderRepository 和 ProductRepository，还必须在返回的 Order 对象中填充 Products 集合。这意味着模拟的 OrderRepository 必须了解模拟的 ProductsRepository 等等。
忽略 LINQ 为我精心创建的这些集合似乎是一种浪费，所以我的问题是，在这种情况下，单个存储库不是更有意义吗？
您的问题描述是一个典型的教科书示例，过多的关于“这很好，那很糟糕”的废话成为开发人员按照其创建方式创建软件而不是查看手头的问题并创建软件来解决该问题的原因。
举个例子：您的问题描述并不是您要解决的问题：您要为您的客户创建一个应用程序，这才是您应该解决的问题。如果您选择的工具让您的生活变得困难，请将它们踢出并使用有效的工具：如果模拟不起作用，为什么还要麻烦呢？哦，因为有人说如果你不嘲笑你的软件就会很糟糕？为什么？
您到处学习了一些 DDD 的东西，但是您错过了一些重要的部分： 产品是一个聚合根。这意味着您应该从其自己的存储库获取产品。是的，这会减轻模型中的导航功能，但如果您严格按照 Evans 书的第二部分的规定创建存储库，那么这对您来说就是 DDD。但是……你应该吗？
如果您无法回答为什么 Product 有自己的存储库，但您可以从 Order 导航到产品，则不应为聚合根创建存储库。为什么那个存储库在那里？如果它在那里，它不应该是获得产品的唯一地点吗？ （所以也不是通过延迟加载！）。
这确实会产生大量开销和您可能不需要的代码（讽刺的是，YAGNI 完全有效）。
好了，吐槽够了。 DDD 的意义在于thinking。因此，领域应该驱动设计，通过实践，您将获得代表现实的领域模型。这并不是说您应该仅仅因为您在应该阅读的地方阅读而实现大量代码。相反，如果您已经识别了域元素、聚合根等，那么您必须将这些类型的行为放置在某个地方，例如在域类内部。您可以将获取逻辑放置在单独的类中，例如订单存储库中的面向订单的获取逻辑，但它不会是严格意义上的存储库（例如，它没有自己的本地缓存等）。这并没有那么糟糕，重要的是你应该为你的客户创造什么。
所以，第一：思考，第二：思考，第三：再思考一次。对你来说似乎合乎逻辑的事情。列出您拥有的选项的优缺点，然后选择最适合您的选项。记录这一选择以及您选择该选择而不是其他选择的原因。这为维护者提供了比任何其他来源更多的价值：您记录了替代方案以及为什么不选择它们，您研究了对您有用的方法，然后选择了一个。
软件工程并不难，只是现在似乎很流行先做后想，没有适当的推理why人们会那样做，而不是另一种方式。
祝你好运 ：）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
