应用服务层方法获取视图表单目录数据

Question

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

Answer 1

从表示层访问您的数据有两种主要策略,它们都有自己的优点和缺点.总结一下:

1.使用应用程序服务层.

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

优点:

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

缺点:

• 添加了接线代码.您必须使用委派几乎所有工作的方法来生成许多服务.如果你做对了就是这种情况.如果你弄错了,你最终会得到一个贫血的领域模型和一个肥胖的应用程序服务.
• 几乎不可能生成一个适合您尚不了解的目的的API.服务调用的适当粒度只能通过其使用来确定.如果您只有一个演示文稿,那么您的应用程序服务可以在不进行更改的情况下重用,这是一种错觉.

我看到的一个子策略是在表示层中使用了应用程序服务和域服务,例如,请参阅本文.虽然我同意作者的立场,即应用程序服务和域服务根本不同,但我不同意这两者应该可以在表示层中使用.当应用程序服务充当边界时,最好地提供具有应用程序层的目的.这确实增加了布线代码的数量,但可以在以后更容易地添加应用程序逻辑.因此,我认为,如果你选择这种战术,你就会一路走下去.

2.直接使用域层.

您只需在表示层中调用存储库和/或服务即可.

优点:

• 减少接线代码.可以更轻松地查看小代码库中究竟发生了什么.
• 您的域模型将在更多地方使用,使其更能抵御外部影响(假设您是一个好的编码器,随着时间的推移会变得更好而不是更糟).

缺点:

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

另一个分策略我在野外看到的是域服务充当表示层的边界对象.因此,表示层无法访问存储库.这我称之为反模式,因为应用程序逻辑,存储库逻辑和域逻辑显然是不同类型的逻辑(对某些人来说这不是很清楚).如果域服务需要满足表示层的所有需求,域服务将成为存储库的委托(坏),应用程序逻辑将最终出现在表示层(可能是可接受的)或/和应用程序逻辑将最终在域服务(坏).DDD中的域服务从不作为边界对象,而只是作为与不是实体或值对象的自然部分的域概念相关的操作的容器.再次,

包起来

我希望我已经减少了这个相当复杂和多方面的讨论,以便您可以选择哪种策略最适合您的使用.软件行业对这些事情没有明确的共识.我通常会选择第一种软件,这种软件可以保证很长时间,或者有多次演示,第二种是软件,未来仍然有些不确定并且只有一个演示文稿.