Martin Fowler建议在领域模型和“数据加载程序”之间使用服务层作为边界。然而,Rockford Lhotka建议将验证构建到业务对象本身中,这正是CSLA.NET所做的。
将此抽象为服务层的好处显然是您的服务层可以协调跨多个业务对象的活动/操作。但是,使用服务层而不是直接使用业务对象进行业务逻辑和验证的其他优点和缺点是什么?
Martin Fowler建议在领域模型和“数据加载程序”之间使用服务层作为边界。然而,Rockford Lhotka建议将验证构建到业务对象本身中,这正是CSLA.NET所做的。
将此抽象为服务层的好处显然是您的服务层可以协调跨多个业务对象的活动/操作。但是,使用服务层而不是直接使用业务对象进行业务逻辑和验证的其他优点和缺点是什么?
我明确地站在Rocky Lhotka这一派的阵营中。我认为您的业务对象应该非常容易在应用程序和用户界面层之间进行“移植”。添加一个额外的“服务层”很可能会添加一个与您的对象相关的依赖项,从而使它们更不“可移植”。
如果您正确编写业务对象框架,则您的业务对象应该能够在各种业务对象之间正确处理验证。CSLA.NET通过具有父/子关系以及相关属性验证的概念来正确执行此操作。
我正在寻找更灵活的领域模型,其中数据和行为分离,但我不认为服务层是适当的行为层。相反,也许可以采用简单的业务逻辑层方法,其中业务实体对象仅公开数据,业务流程对象仅公开行为,并且这些行为包括验证方法。
一个好处是,根据业务流程耦合的松紧程度,您可以将验证应用于更广泛的协变量甚至不变类型。考虑一下验证“FirstName”和“LastName”字段,进一步考虑这些字段在任何大型系统中可能存在于半打或更多不同的实体上。将过程与数据分离将确保您可以实现一次验证过程并将其应用于提供相同数据的许多对象。
我注意到,领域模型“应该”由领域对象组成,这些对象是数据和行为的融合,这是Fowler / Evans的概念,约为2000-2002年(紧随着迅速迁移到分布式信息系统而不是2层应用程序之后)。
你有什么想法?