1

我正在设计一个 C# 分层应用程序，我想知道我的域对象是否可以了解存储库和 ServiceLayer。

如果不是 - 我如何解决像 Article.CalculatePrice() 或 Offer.CalculatePrice 这样的复杂函数，恕我直言，它们应该遍历所有项目并汇总 Item.GetPrice()。

我正在使用 EF5 顺便说一句。

更新： 我的场景如下：我必须在不遵循任何可以想象的规则和某种奇怪的价格计算场景的遗留数据库之上构建它：

例如，我有一个Article A { Type: Curtain, Color: Blue, Dimension: 200cm }，但没有在数据库中定义特定价格的文章 -> 所以我必须查看所谓PriceGroups 的哪些价格构建规则适用。

例如，可能有以下组适用于该文章：

 - Article A { Type: Curtain, Color: Blue, Dimension: 200cm } <-- does not exist
 - PriceGroup { Type: Curtain, Color: Blue, Dimension: NULL, Price: -5 EUR (*relative* price) }
 - PriceGroup { Type: Curtain, Color: NULL, Dimension 200cm, Price 25 EUR (*absolute* price) }

问题是：PriceGroup 和 Article 不能以任何方式聚合，并且价格组不是分层对齐的，而是按规范应用的。

所以：恕我直言，ArticlePriceService 必须知道 PriceGroups，因此如果找不到 ArticlePrice，它必须返回从组计算的价格。所以，如果我把这整个东西装进一个域对象中，我的 ArticleDO 就必须知道 ArticlePriceService，它必须知道 PriceGroupService？

我真的很困惑如何解决这个问题。请尝试提供一个例子或我..

4

1 回答 1

1

恕我直言，这应该遍历所有项目并总结 Item.GetPrice()。

如果您需要一个存储库来Items单独获取，那么听起来您可能没有明确定义的聚合。理想情况下，Article和Offer聚合应该已经拥有这些信息，并且能够在没有任何外部数据的情况下进行计算。

如果需要一些外部数据（例如增值税率），那么这种行为应该封装在Domain Service中。在这种情况下，也许ArticlePriceCalculator和OfferPriceCalculator服务有关。

更新 似乎您的旧数据库正在渗入您的域。这是需要避免的事情。就普遍存在的语言而言，保持领域“纯粹”，根本不要让数据库的性质影响您的领域模型设计。一旦您有了一个精心设计的表达业务关注点（而不是数据库关注点）的域模型，您就可以考虑从数据库中获取数据并进入模型的最佳方式。鉴于您有一个遗留数据库，我强烈建议您使用反腐败层. 该层旨在为您的美丽域和丑陋的数据库之间提供一道屏障。应在此处处理数据库模式中的任何怪癖和怪癖，以免影响域模型的设计。

于 2013-06-17T09:33:52.193 回答