我发现JPA，或类似的，不鼓励DAO模式
我发现JPA，或类似的，不鼓励DAO模式。 我不知道，但我觉得这样，尤其是服务器pipe理的JTA经理。
经过充分的动手使用DAO模式，我开始围绕这种模式devise基于JPA的应用程序。 但它不适合，国际海事组织。 我倾向于失去相当JPA和所有function。
那么，假设你用一个悲观的locking激发了一个查询，并且从DAO方法返回了一个entite列表。 返回时，事务结束并locking消失（服务器pipe理的JTApipe理器的情况）。 所以，没有意义，松散地说。 但是有一些有效的例子。
另一个例子是更微不足道的。 假设你启动了一个查询来获得一个实体，它与其他实体有一个延迟的加载一对多的关联。 在返回DAO方法后，事务结束。 延迟加载不会工作了，你只是得到null或什么的。 为了应付这个问题，我们手工加载它。 我们做一些像a.getBList().size() 。
因此，IMO最好不要专门制作一个DAO，并且在你的商业bean中这样做，这样你就可以利用这些有用的特性。 或者ORM API可以被认为是一个DAO /数据层本身。 所以，我们不需要再做一个。
你们都在想什么？
注：我绝对不会说DAO模式已经过时。 事实上，这取决于情况。
对于简单的应用程序，从EJB中直接使用EntityManager并跳过DAO模式（我厌倦了编写太多的代码）看不到任何问题。 我的感觉确实是这是JPA和Java EE API所鼓励的。 但是对于更复杂的应用程序（从存储过程的数据访问，平面文件…），这仍然是合理的。 所以你是对的，这取决于:)
在JPA中，你会发现其他一些开明的观点杀死了DAO？ 在InfoQ上，但您不会对内容和结论感到惊讶，可以总结为：您不再需要DAO模式来访问标准数据，您可能需要它来处理更复杂的情况，但我们生活没有它更好。
如果您没有将DAO本身定义为事务性的，那么您将不会遇到这些问题。
服务层应该是事务性的，因为事务应该跨越多个操作。 将每个插入/更新放在事务中并不是最好的scheme。
随着spring，你很容易实现。 没有它，你可能再次在你的DAO中包含事务逻辑 – dao.beginTransaction()和dao.commitTransaction()并使用来自服务层的。
据我所知，你build议直接在服务类中使用EntityManager可能比有一个包装DAO类更好。 我不同意有一个原因。 在您的服务类中使用DAO类（最好是接口），您根本就不依赖于JPA API。 您不必构造Query对象或类似的东西。 这可能不是一个很大的优势，但你会同意这是一个最好的做法。 你可以稍后切换到普通的JDBC，纯文本，XML或其他任何方式，只需更改DAO即可。
这虽然被广泛用作为什么你应该在另一层抽象某个东西的例子，但是往往只是一个过度devise。 但是有时候，所有的数据库访问操作都是通过一个地方进行的，这意味着你可以添加日志logging，访问级别检查等等（是的，有时DAO不是一个特别合适的方法）。
所以最终，要回到你的观点 – 这取决于。
DAO用于deviseangular度，而JPA是用于数据访问function的一些“官方”包装。 JPA没有办法杀死DAO – 它可以使DAO更容易实现，也许这么容易，DAO看起来很简单，可以忽略。 但是没有DAO层，devise优势就不复存在了。
当然，对于“简单”的项目，可以忽略不计。 如果项目“足够简单”，许多事情可以被“忽略”。
