8

Martin Fowler 建议使用服务层作为域模型和“数据加载器”之间的边界。但是，Rockford Lhotka 建议将验证构建到业务对象本身中，而这正是 CSLA.NET 所做的。

将其抽象为服务层的好处显然是您的服务层可以跨多个业务对象协调活动/操作。但是，与直接使用业务对象进行业务逻辑和验证相比，使用服务层的其他优点和缺点是什么？

4

3 回答 3

4

我不确定你是否已经弄清楚了。

PEAA 中的 Martin Fowler 建议是 UI（或客户端）和域/数据层之间的 API 服务层。它将公开客户端可以使用的任何功能。

如果您查看域模型（此处）

包含行为和数据的领域对象模型。

域层将包含这些对象，这些对象将具有操作/验证（行为）和状态（数据）

这些对象可以在其他应用程序中重用，这也取决于您的设计。领域层不应该依赖于服务层

因此，考虑到域对象具有行为（包括验证）和数据。服务层是您希望您的应用程序公开的（功能性的）。IE 添加一个客户或帐户，计算月底的账单。

看看Sharparchitecture的布局（http://www.sharparchitecture.net/）

这是我对这种材料的理解。

高温高压

骨头

于 2009-09-20T18:48:02.110 回答
3

我肯定在洛基洛特卡营地。我相信您的业务对象应该很容易在应用程序和 UI 层之间“移植”。添加额外的“服务层”很可能会为您的对象添加依赖关系，因此会使它们的“便携性”降低。

如果您正确编写业务对象框架，您的业务对象应该能够正确处理各种业务对象之间的验证。CSLA.NET 通过拥有父/子关系以及依赖属性验证的概念正确地做到了这一点。

于 2009-06-11T13:04:17.690 回答
0

我正在寻找一个更灵活的域模型，其中数据和行为分离，但我不相信服务层是适合行为的层。相反，也许可以采用一种简单的业务逻辑层方法，其中业务实体对象仅公开数据，业务流程对象仅公开行为，其中包括验证方法。

一个好处是，根据业务流程耦合的松散程度，您可以将验证应用于更广泛的协变，甚至可能是不变的类型。考虑一下验证“FirstName”和“LastName”字段，并进一步考虑这些字段在任何大型系统中可能存在于六个或更多不同的实体上。将流程与数据分离将确保您可以实现一次验证流程并将其应用于提供相同数据的许多对象。

我注意到域模型“应该”由融合了数据和行为的域对象组成的理想是 Fowler/Evans 的概念，大约在 2000-2002 年（在向分布式信息系统快速迁移之后不久而不是 2 层应用程序。）

想法？

于 2012-07-12T11:13:53.290 回答