我已经看到很多书和文章示例都说将验证代码放在您的服务层中。保持Domain Objects“哑”（又名纯POCO）并处理域对象在服务层中可能进行的所有验证。
服务层似乎（或者至少可以）负责这么多;用户身份验证，角色身份验证，IoC的脚本依赖对象（记录器，错误处理程序等），脚本域对象，脚本存储库以及将域对象传入和传出存储库......哇！
不在服务层中创建所有这些规则会对域对象构成重大威胁吗？例如，一些程序员决定直接针对您的域对象编写消费代码并完全绕过服务层？那将是糟糕的，但这是一个可信的情况。
如果您要在服务层中承担很多责任，包括所有域对象验证，有没有办法“保护”您的域对象是否有人试图直接编写脚本？例如，也许某种方式你的域对象现在没有被某个客户端使用（在这种情况下，服务层？）。
好的设计让我觉得Domain Objects不应该知道谁在调用它们以及它们是如何被调用的。
如果没有办法“锁定”域对象，那么为什么有这么多文章，书籍等建议将域对象验证放在服务层中呢？我想通过采取防御性编程位置，你应该构建你的域对象防弹，并依靠你的服务层获得一个简单的代码层来转发和接收UI和BAL / DAL之间的请求。 / p>
是否有人从绕过服务层的人那里“滥用”他们的域对象有一些真实的项目经验？
答案 0 :(得分：2)
我认为你可能误解了POCO的目的。据我所知，POCO不是一个只有属性和属性的贫血域对象。相反，POCO根本不依赖于框架或复杂的继承模型。该对象是灵活的，只关心它在域中的作用。
答案 1 :(得分：1)
它们是两种不同的设计理念。富域模型与贫困域模型。
简短回答是肯定的，您可以阻止直接访问您的域对象。
您可以使用多种技术来实现：
1）您可以通过仅使用唯一的公共方法为getter来使所有面向公众的域对象不可变（即，您无法更改数据）。修改对象的所有方法都可以受到保护或包私有，因此只有正确打包的服务才能访问它们（至少在Java中） 2）您只能向外部开发人员公开单独的类 - 因此，如果您有一个Person域类，您可以拥有一个您传递的PersonInfo类，它只会包含信息。 3）您应该向您的应用消费者公开一致的API。您基本上阻止它们绕过您的服务层。