3

我正在尝试使用分层模式和 DDD。但是我找不到应该在单个模型实体的编辑视图中加载用于填充组合框和列表框的目录的位置。我是否应该在应用程序服务层中创建一个方法以在视图模型包装器中获取单个视图所需的所有列表？或者我应该为我需要的每个列表创建一个方法？还是根本不属于服务层？

4

1 回答 1

9

从表示层访问数据有两种主要策略，它们各有利弊。总结一下：

1. 使用应用服务层。

应用程序服务层用作表示层到下面各层的 API。这意味着应用程序服务是边界对象。您仍然可以通过应用程序服务公开实体和值对象，但服务和存储库仍然对表示层完全隐藏。

优点：

  • 在层之间创建清晰的分离，这使得代码更容易开发、重构、维护和测试，尤其是在一个团队中或与多个团队一起工作时。
  • 如果需要在您的应用程序之上构建任何其他演示文稿，您已经有一个 API 可以构建它。
  • 您可以将表示逻辑与应用程序逻辑分开。

缺点：

  • 添加了接线代码。您必须使用委托几乎所有工作的方法来生成大量服务。当你做对时就是这种情况。如果你弄错了，你最终会得到一个贫乏的领域模型和一个肥胖的应用程序服务。
  • 几乎不可能产生一个合适的 API 来服务于你还不知道的目的。服务调用的适当粒度只能通过它们的使用来确定。如果您只有一个演示文稿，那么您的应用程序服务将无需更改即可重用是一种错觉。

我看到的一个子策略是应用程序服务和域服务都在表示层中使用，例如，请参阅这篇文章。虽然我同意作者的立场，即应用程序服务和域服务根本不同，但我不同意两者都应该在表示层内使用。当应用程序服务作为边界时，拥有应用程序层的目的最能发挥作用。这确实增加了接线代码的数量，但更容易在后期添加应用程序逻辑。因此，我会争辩说，如果您选择这种策略，那么您将一路走来。

2.直接使用领域层。

您可以简单地从表示层中调用存储库和/或服务。

优点：

  • 更少的接线代码。可以更轻松地查看小型代码库中到底发生了什么。
  • 您的域模型将在更多地方使用，使其更能抵抗外部影响（假设您是一名优秀的编码员，随着时间的推移，事情会变得更好而不是更糟）。

缺点：

  • 纯应用程序逻辑要么最终出现在您的表示层中。如果需要添加另一个演示文稿，您将不得不复制该逻辑或恢复到第一个策略。
  • 由于您的域模型可能提供多种实现相同目标的方法，因此存在逻辑重复的风险。重复代码易于检测且难以预防，重复逻辑难以检测且易于预防。

另一个子策略我在野外看到的是域服务充当表示层的边界对象。因此，表示层无法访问存储库。这我称之为反模式，因为应用程序逻辑、存储库逻辑和域逻辑显然是不同类型的逻辑（尽管对某些人来说这不是很清楚）。如果表示层的所有需求都需要通过域服务来满足，那么域服务将成为存储库的委托（不好）并且应用程序逻辑将最终在您的表示层中（可能是可以接受的）或/并且应用程序逻辑将最终在域服务中（坏）。DDD 中的域服务从不意味着边界对象，而只是作为与域概念相关的操作容器，这些域概念不是实体或值对象的自然部分。再次，

包起来

我希望我已经减少了这个相当复杂和多方面的讨论，以便您可以选择最适合您使用的策略。软件行业对这些事情没有明确的共识。我通常选择第一种策略用于保证长期存在或有多个演示的软件，而第二种策略用于未来仍然有些不确定并且只有一个演示的软件。

于 2013-10-16T10:35:27.077 回答