首先，让我解决您在第一种方法中列出的“缺点”：
您将开始实现依赖于客户端（hibernate）的代码。理想情况下，一个类不知道其调用者。
您在这里使用“依赖”一词有点麻烦。Hibernate不是“客户端”。 您
（作为开发人员/架构师/您拥有什么）选择了一个框架来实现您的持久性。因此，您将在某些使用（因此取决于）Hibernate的地方编写一些代码。就是说，上面的域对象中
没有 对Hibernate的依赖。如果愿意的话，有一个无参数的构造函数是语义要求。它没有引入实际的依赖关系。将Hibernate切换为JPA /
Toplink / raw jdbc /您将拥有什么，您将不必更改域对象代码中的任何内容。
此解决方法的一个特定问题是，如果满足不变量，则不会检查由hibernate启动的实例。您信任从数据库加载的有问题的数据。即使您的应用程序是唯一使用此特定数据库模式的应用程序，管理员也始终可以进行临时更改。
您 不必“信任”
数据（更多内容请参见下文）。但是，我认为这种说法没有根据。如果要在多个应用程序中修改数据，则应在某个常见的较低层执行验证，而不要依赖每个单独的应用程序来验证数据。所述公共层可以是数据库本身（在简单情况下），也可以是提供要由多个应用程序使用的公共API的服务层。
此外，作为 日常工作的 一部分，管理员 直接
对数据库进行更改的想法是完全荒谬的。如果您在谈论特殊情况（错误修复，您拥有什么），则应将其视作此类情况（也就是说，此类情况很少发生，验证此类“关键”变更的责任在于进行变更的人；不在堆栈中的每个应用程序上）。
综上所述，如果您确实想在 加载
对象时对其进行验证，则可以轻松实现。定义一个
Valid具有
validate()方法的接口，并让所有相关领域对象实现该方法。您可以从以下位置调用该方法：
- 加载对象后的DAO /服务。
- Hibernate Interceptor或Listener-两者都在Hibernate配置中设置；您需要做的就是实现其中一种，以检查要加载的对象是否实现
Valid
，如果是，则调用该方法。 - 或者，您可以使用Hibernate Validator，但是它将为您的域对象和Hibernate绑定在一起，因为您需要对其进行注释。
最后，就“构造函数注入”而言，我不知道任何 直接 支持它的框架。这样做的原因很简单-它仅对 不可变
实体有意义（因为一旦有了设置器，无论如何都要进行验证），因此意味着大量工作（处理构造函数参数映射等）几乎为零。净效应。事实上，如果你 是
关注具有不可变对象一个无参数的构造你总是可以不将它们映射为实体，而是通过HQL加载它们该 做
支持构造器注入：
select new A(x, y) from ...
更新 （以解决托马斯评论中的问题）：
- 我只是为了完整性而提到拦截器。在这种情况下，侦听器更为合适。实体完全初始化后，将调用PostLoadEventListener。
- 再说一次，拥有no-arg构造函数不是依赖关系。是的，这是一个合同，但是它不会以任何方式将您的代码与Hibernate绑定在一起。就合同而言，它是javabean规范的一部分（实际上，它的限制较少，因为构造函数不必是公共的），因此在大多数情况下，您还是应该遵循它。
- 访问数据库。“数据库重构和迁移很常见”-是的。但这仅仅是代码；您编写，测试，运行集成测试，然后将其部署到生产环境。如果您的域模型对象使用
StringUtil.compare()
您在某个实用工具类中编写的某些方法，那么您无需使用它重新检查结果，对吗？同样，域对象也不必检查您的迁移脚本没有破坏任何东西-您应该对此进行适当的测试。“能够进行即席查询是其中的一项功能”-绝对如此。 查询 。例如，与用于报告的“只读”查询一样（即使如此，在许多情况下，更适合使用API）。但是手动数据 处理 是非紧急的-绝对不是。 - 可变性使构造函数注入 无关紧要 。我并不是说您不能拥有非默认构造函数-可以，并且可以在代码中使用它。但是，如果您有setter方法，则不能使用构造函数进行验证，因此是否存在并不重要。
- HQL构造函数注入和关联。就我所知， 嵌套 构造函数将无法正常工作（例如，您不能编写
select new A(x, y, new B(c, d))
；因此，要获取关联，您将需要在select子句中将它们检索为实体，这意味着它们自身需要无参数的构造函数:-)或者，您也可以在“主要”实体上有一个构造函数，该构造函数将所有需要的嵌套属性用作参数并在内部构造/填充关联，但是这很疯狂：-)
