问题标签 [domain-object]

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

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

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

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

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

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

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

什么是软件架构中的领域对象和领域服务？我不熟悉它们，或者它们与业务逻辑层有何不同？

通过查看 Zend 快速入门教程中的域对象示例，以及考虑 DAO/VO 模式的其他示例，它们似乎都非常相似。

我们可以推断说“值对象”与说“域对象”是一样的吗？

如果没有，您能否澄清它们之间的区别？

一个的功能是什么，如果另一个的功能是什么？

我问这个是因为，两者都是由 getter 和 setter 组成的，仅此而已。看来，他们做同样的功能......

更新：

因此，Zend Framework 快速教程文档称之为域对象：

1)严格来说，我们面对的是“贫血的领域对象”吗？

2）是否仅仅因为它包含域逻辑而被称为“域对象” ？

3)如果是这种情况，那么，那些包含 findBookByAuthor() 等方法的映射器；他们也在处理域逻辑，对吗？它们也可以被视为域对象吗？

非常感谢

如果我错了，请纠正我。

我们可以说领域模型来表示：

a) MVC 结构的 M 部分，在 M 部分上应用了领域驱动设计模式。

b)以某种方式的实体、它们的属性和关系的方案。也可以表示 MVC 上的 M 部分，但在这种情况下，无论使用何种模式。

c)领域模型设计模式，其中“领域模型创建互连对象的网络”；

d)作为域对象（例如，可以是我们的 MVC 模型上的一个对象，涉及某个域）；

我们可以说d)与b)相同吗？

非常感谢。

我的 ORM 正在生成反映数据库表结构的对象。这个对象是可扩展的，所以我可以添加新的属性和方法。这个对象不包含任何持久性逻辑，所以我猜它们是持久性无知的。

我应该将此对象用作我的域对象还是应该为主域模型创建新对象？

作为创建新对象的专家，我认为当数据库表发生更改时，它不会破坏应用程序。

作为创建新对象的一个​​缺点，我会考虑应用程序中的额外映射和更多复杂性。

我知道应该将域逻辑放入域对象中。但是，如果我的域逻辑需要来自数据库的数据怎么办？（例如检查唯一值、计算值......等）我认为将存储库注入我的域对象不是正确的事情。此外，服务层不应包含业务规则。那么如何解决这种业务逻辑呢？

将通过调用 Grails 域对象上的 validate() 收到的面向开发人员的验证错误列表转换为面向用户的错误消息的最佳方法是什么？

示例：
值为 [x] 的类 [class testproj.AuthUser] 的属性 [email] 不是有效的电子邮件地址

宁愿阅读：
给定的电子邮件不是有效的电子邮件地址

有没有内置的东西已经这样做了？

在Sets中使用域对象或作为 Maps 中的键是一种不好的做法吗？

过去我做过很多这样的事情

但是我注意到，当findAllByAuthorLike可能返回 Hibernate 代理对象列表com.me.Book_$$_javassist_128但findByTitleLike会返回正确com.me.Book对象时，我经常遇到问题。这会导致集合中的重复，因为真实对象和代理被认为不相等。

我发现在使用像这样的域对象集时需要非常小心，而且我觉得这可能是我一开始不应该做的事情。

另一种方法当然是使用 id 的集合/映射，但这会使我的代码冗长且容易产生误解

@Burt：我认为Grails 域类已经做到了这一点，至少这样等于/比较是在类/id 而不是对象实例上完成的。你的意思是休眠代理的特殊比较器吗？

在我正在处理的一个项目中，我们约定 Hibernate 对象（映射在 *.hbm.xml 文件中的对象）以后缀“Hib”结尾。例如，我们将有“UserHib”和“OrderHib”等。

我们发现它有用的原因是，当查看驻留在 dao 层之外的代码时，很直观地知道这些对象是域对象。它还标记潜在问题（例如，延迟初始化、代理对象）。

现在我需要添加一些将通过常规 jdbc 层访问和创建的域对象，我想知道什么是有用的后缀，如果有的话？使用相同的后缀会增加混淆（.hbm.xml 文件中未找到新对象）还是减少混淆（域对象的统一后缀）？

有什么想法吗？

我有几个类继承自一个Admin类：Manager,Translator等。

Admin是一个聚合，所以应该有它自己的Repository。但是，某些查找 Managers 或 Translators 的方法可能特定于这些类。其他可能对所有管理员都是通用的。

这里的最佳做法是什么？我是不是该：

• 将所有查找管理员的方法放在一个存储库中？
• 或者使用存储库的层次结构来模仿域模型类的层次结构，然后有一个ManagerRepository和一个TranslatorRepository扩展一个AdminRepository？