4

我已经看到很多书籍和文章示例都说要将验证代码放在您的服务层中。保持域对象“哑”（又名纯 POCO）并处理域对象可能在服务层中执行的所有验证。

服务层似乎（或至少可以）负责这么多；用户身份验证、角色身份验证、为 IoC 编写脚本依赖对象（记录器、错误处理程序等）、编写域对象脚本、编写存储库脚本以及将域对象传入和传出存储库……哇！

在服务层中创建所有这些规则不会对您的域对象构成重大威胁吗？例如，如果某些程序员决定直接针对您的域对象编写消费代码并完全绕过服务层，会发生什么情况？这将是糟糕的，但一个可信的情况。

如果您打算将很多职责放在服务层中，包括所有域对象验证，是否有办法“保护”您的域对象，是否有人试图直接编写脚本？例如，也许你的域对象现在没有被某个客户端使用（在这种情况下是服务层？）。

好的设计让我认为域对象不应该知道谁在调用它们以及如何调用它们。

如果没有办法“锁定”域对象，那么为什么有这么多文章、书籍等建议将域对象验证放在服务层中呢？我想通过采取防御性编程立场，您应该构建您的域对象以防弹，并依靠您的服务层来提供一个简单的代码层来在 UI 和 BAL/DAL 之间转发和接收请求。

有没有人从绕过他们的服务层的人那里“滥用”他们的域对象的一些实际项目经验？

4

2 回答 2

2

I think you may misunderstand the purpose of a POCO. A POCO, as I understand it, is not an anemic domain object with only properties and attributes. Rather a POCO simply is not tied to a framework or complicated inheritance model. The object is flexible and only concerned about its role in the domain.

于 2011-02-25T18:30:05.357 回答
1

它们是两种不同的设计理念。富域模型与贫血域模型。

简短的回答是肯定的，您可以防止直接访问您的域对象。

您可以使用多种技术来做到这一点：

1）您可以通过仅让唯一的公共方法成为吸气剂来使所有面向公众的域对象不可变（即您不能更改数据）。所有修改对象的方法都可以受到保护或封装私有，因此只有正确打包的服务才能访问它们（至少在 Java 中）
2）您只能向外部开发人员公开单独的类——所以如果您有一个 Person 域类，您可以有一个您传递的 PersonInfo 类，它只包含信息。
3) 您应该向您的应用程序消费者公开一个连贯的 API。您基本上可以防止他们绕过您的服务层。

于 2011-02-24T18:01:12.380 回答