是否应该从数据访问层（或接口）返回原始的Hibernate注释POJO？
我了解将数据层对象（DAO）分离到它们自己的层中，从而从DAO和Service层（JPA / Hibernate +Spring）中概述的服务和业务层中抽象出数据访问逻辑和数据源细节以及其他问题。我具有创建这些层的经验，但是我一直使用原始JDBC或类似的与数据库进行交互的较低级别的方法（例如Spring的SimpleJDBC），并且是Hibernate的新手。
我的问题是，以原始JDBC或其他方式实际在数据访问层处理结果集（或围绕它的薄包装）时，将数据粘贴到其中的结果POJO非常干净，不知道在哪里数据来自哪里，我从不担心将这些数据返回到服务层以及其他地方。但是似乎在Hibernate中，POJO批注中有很多特定于Hibernate
/数据结构的逻辑（诸如1到许多映射，延迟加载首选项等）。我感到不舒服，从我的DAO返回它们（或它们的Collection），直到我的服务层，并且很想让所有POJO都实现我传递回来的接口。这是好的做法，还是过于复杂？
问题答案：
注释具有将某些框架知识与Java对象耦合的一个缺点。这就是您没有单独的元数据定义所要付出的代价。但是，POJO仍然是POJO，从实际的角度来看，仅凭注释我就没有充分的理由使设计复杂化。
让我们考虑一下，如果您将使用XML映射，您是否还会担心？最有可能-不会。因此，支付罚款并继续前进；并且在不太可能的情况下，如果您要更改持久性框架-
您将继续删除这些注释。在所有情况下，它们都不应对DAO层之外的代码产生任何副作用。
只是我的2美分…
-
问题内容： 我了解将数据层对象（DAO）分离到其自己的层中，从而从[DAO和Service层（JPA / Hibernate +Spring）中概述的服务和业务层中抽象出数据访问逻辑和数据源细节以及其他问题。我具有创建这些层的经验，但是我一直使用原始JDBC或类似的与数据库的较低层接口（例如Spring的SimpleJDBC），并且是Hibernate的新手。 我的问题是，以原始JDBC或其他方式
-
我在Hibernate（4.3.0）中遇到了一个问题，其中as单向@OneToMany返回重复项。 我的数据库结构（MySQL与InnoDB），其中作为“条目”表与“entry_address”表有1： N关系。“条目”表是主表，“entry_address”是“条目”表的子表。 下面是“entry”实体的最小代码。 以下是“entry_address”实体的最小代码： 这是Hibernate完成
-
问题内容： 但是我想知道哪个更好？通过属性访问还是通过字段访问？每种都有哪些优点和缺点？ 问题答案： 我更喜欢访问器，因为我可以在需要时向访问器添加一些业务逻辑。这是一个例子： 此外，如果您将其他库（例如一些基于JSON转换的库，BeanMapper或Dozer或其他基于getter / setter属性的Bean映射/克隆库）添加到混合库中，则可以确保该库与持久性同步经理（都使用getter /
-
我的问题是：用“async”定义一个返回“promise”的函数（形式上）正确吗？是否容易出现“内存泄漏”？ 对于那些喜欢用自然语言阅读我用js发布的内容的人。 我正在给一个知道JS是如何真正实现的人打电话，然后知道引擎是如何管理我提出的场景的：我们应该避免对返回“promise”的函数使用“async”吗？ 我提出的问题不会改变任何人的生活，最终也不会影响表演。事实是，在编写代码时，我喜欢关注代
-
我在这里遵循Spring启动教程： 使用rest服务的Spring boot教程 本教程工作正常，但是否有一种方法可以在原始JSON被解组（通过jackson JSON处理库）之前打印它以用于日志记录？
-
我正在使用Spring开发一个应用程序。我需要使用注释。我有和，这样。这里我很困惑应该在哪里保留注释。 我应该用注释接口还是实现？这两种做法有何不同？