Martin Fowler建议在领域模型和“数据加载程序”之间使用服务层作为边界。然而，Rockford Lhotka建议将验证构建到业务对象本身中，这正是CSLA.NET所做的。
将此抽象为服务层的好处显然是您的服务层可以协调跨多个业务对象的活动/操作。但是，使用服务层而不是直接使用业务对象进行业务逻辑和验证的其他优点和缺点是什么？
3个回答
4
我不确定您是否已经弄清楚了。
Martin Fowler在PEAA中建议将Service层作为UI（或客户端）和Domain/Data层之间的API。 它将公开任何可以被客户端使用的功能。
如果您查看域模型（这里）
一个包含行为和数据的领域的对象模型。
域层将包含这些对象，这些对象将具有操作/验证（行为）和状态（数据）。
这些对象可以在其他应用程序中重复使用，这也取决于您的设计。 域层不应依赖于服务层。
因此，考虑到域对象具有行为（包括验证）和数据。 服务层是您希望应用程序公开的内容（以实现功能）。例如添加客户或帐户，计算月底账单。
请查看sharp architure的布局（http://www.sharparchitecture.net/）
这是我对这个材料的理解。
希望对您有所帮助。
bones
Martin Fowler在PEAA中建议将Service层作为UI（或客户端）和Domain/Data层之间的API。 它将公开任何可以被客户端使用的功能。
如果您查看域模型（这里）
一个包含行为和数据的领域的对象模型。
域层将包含这些对象，这些对象将具有操作/验证（行为）和状态（数据）。
这些对象可以在其他应用程序中重复使用，这也取决于您的设计。 域层不应依赖于服务层。
因此，考虑到域对象具有行为（包括验证）和数据。 服务层是您希望应用程序公开的内容（以实现功能）。例如添加客户或帐户，计算月底账单。
请查看sharp architure的布局（http://www.sharparchitecture.net/）
这是我对这个材料的理解。
希望对您有所帮助。
bones
- dbones
3
我明确地站在Rocky Lhotka这一派的阵营中。我认为您的业务对象应该非常容易在应用程序和用户界面层之间进行“移植”。添加一个额外的“服务层”很可能会添加一个与您的对象相关的依赖项，从而使它们更不“可移植”。
如果您正确编写业务对象框架，则您的业务对象应该能够在各种业务对象之间正确处理验证。CSLA.NET通过具有父/子关系以及相关属性验证的概念来正确执行此操作。
- Jamie Wright
1
我还要补充一点，有些业务对象也可能存在于协调中。例如，您不会编写将订单转换为发票所需的行为，而是会有一个OrderConverter来检查订单并在有效时进行转换。我通常看到的“服务”对象基本上是一堆几乎没有关联的方法。它们都对存储做某些事情，但除此之外没有关系。在Csla中，这些方法通常会封装到单独的类中，该类完全了解用例，即它知道如何使订单成为发票的所有内容。 - Andy
0
我正在寻找更灵活的领域模型，其中数据和行为分离，但我不认为服务层是适当的行为层。相反，也许可以采用简单的业务逻辑层方法，其中业务实体对象仅公开数据，业务流程对象仅公开行为，并且这些行为包括验证方法。
一个好处是，根据业务流程耦合的松紧程度，您可以将验证应用于更广泛的协变量甚至不变类型。考虑一下验证“FirstName”和“LastName”字段，进一步考虑这些字段在任何大型系统中可能存在于半打或更多不同的实体上。将过程与数据分离将确保您可以实现一次验证过程并将其应用于提供相同数据的许多对象。
我注意到，领域模型“应该”由领域对象组成，这些对象是数据和行为的融合，这是Fowler / Evans的概念，约为2000-2002年（紧随着迅速迁移到分布式信息系统而不是2层应用程序之后）。
你有什么想法？
- Shaun Wilson
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接