Martin Fowler suggests使用服务层作为域模型和“数据加载器”之间的边界。但是，Rockford Lhotka建议在业务对象本身中构建验证，这正是CSLA.NET所做的。
将此抽象到服务层的好处显然是您的服务层可以跨多个业务对象协调活动/操作。但是，使用服务层而不是直接使用业务对象进行业务逻辑和验证有哪些其他优点和缺点呢？
答案 0 :(得分：4)
我不确定你是否已经弄明白了。
Martin Fowler在PEAA中的建议是服务层是UI（或客户端）与域/数据层之间的API。它将公开客户端可以使用的任何功能。
如果您查看域模型（Here）
包含行为和数据的域的对象模型。
域层将包含这些对象，这些对象将具有操作/验证（行为）和状态（数据）
这些对象可以在其他应用程序中重用，这也取决于您的设计。域层不应该依赖于服务层
因此，考虑到Domain对象具有行为（包括验证）和数据。服务层是您希望应用程序公开的（功能上）。 IE添加客户或帐户，计算月末的账单。
看一下尖锐的architure的布局（http://www.sharparchitecture.net/）
这是我对这个材料的理解。
HTH
骨
答案 1 :(得分：3)
我肯定是在Rocky Lhotka的阵营中。我相信您的业务对象应该很容易在应用程序和UI层之间“移植”。添加额外的“服务层”很可能会增加对象的依赖性，从而使它们不那么“可移植”。
如果正确编写业务对象框架，业务对象应该能够在各种业务对象之间正确处理验证。 CSLA.NET通过父/子关系以及依赖属性验证的概念来正确地做到这一点。
答案 2 :(得分：0)
我正在寻找一种更灵活的域模型，其中存在数据和行为的分离，但我不认为服务层是适合该行为的层。相反，也许可以采用一种简单的业务逻辑层方法，其中业务实体对象仅公开数据，而业务流程对象仅公开行为，其中行为是验证方法。
一个好处，取决于业务流程耦合的松散程度，您可以将验证应用于更广泛的协变量甚至可能是不变类型。考虑一下验证“FirstName”和“LastName”字段，并进一步考虑在任何大型系统中这些字段可能存在于六个或更多不同的实体上。将过程与数据分开将确保您可以实施一次验证过程并将其应用于提供相同数据的许多对象。
我注意到，域模型'应该'由域对象组成的理想是数据和行为的融合，这是Fowler / Evans的概念，大约在2000 - 2002年（在快速迁移之后不久）分布式信息系统而不是2层应用程序。）
思想？