Java EE 6 设计模式

Question

我想了解可以在 Java EE 6 实现中应用的设计模式。

• MVC。
• GOF.
• 道
• 持久关系映射
• 池
• CEC
• 实体控制边界 (ECB)
• 还有很多其他的

JPA 是否消除了对 DAO 的使用？
请提供其他可以学习的模式。

Answer 1

这里有一个很好的参考：http://martinfowler.com/eaaCatalog/

也在这里：http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html

此外，JPA 不一定消除对 DAO 层的需求。相反，您的 DAO 层仍会构建 JPA 查询，可能在 finder 方法中，并返回这些查询返回的实体。

您可以消除 DAO 层，而是直接在您的业务层中访问 JPA 实体，但个人仍然喜欢保持单独的持久性 (DAO) 和业务层，特别是在我最终不得不混淆的情况下一些带有普通 JDBC 的 JPA 等。

here 对辩论进行了很好的总结。最好的答案是视情况而定。如果您的应用程序很复杂，并且在某些情况下您可能会直接访问 JDBC（因为 JPA 和 ORM 工具并不能解决所有问题，并且在某些事情上非常糟糕），或者如果您需要从刚刚不使用的源中提取数据'与 ORM 一起工作得不好，无论如何你都需要一个 DAO 层，所以在我看来，我宁愿保持一致并为所有事情使用 DAO 层。它通常没有那么复杂，它将您的业务逻辑与您的持久性逻辑隔离开来，我认为这是一件好事。但是，这是个人喜好问题，如果您的应用程序足够简单，那可能就有点过头了。

有一个很好的推荐通用 DAO 模式可以与 JPA here 一起使用。这使您可以享受 DAO 的好处，因为您始终可以为特定的 DAO 覆盖它，同时保持更标准和典型的数据库交互更简单。

Answer 2

如果您使用 Java EE 6（不是 Java EE 5），那么在 J2EE 中使用的任务中不再需要一些技术 J2EE 模式。

例如，使用注入代替 ServiceLocator。

@见http://pawelstawicki.blogspot.com/2010/07/review-real-world-java-ee-patterns.html

---

仍然需要 GOF 模式，因为它们不（仅）与 Java EE 相关。

一般来说：模式有一个意图：他们希望为问题产生解决方案/最佳实践，并具有由环境提供的一组给定功能（在您的情况下：它是 Java、Java EE 6、. ..)

• 如果问题解决了：您不再需要该模式
• 如果自从喜欢模式后环境发生了变化，那么您必须重新考虑模式，因为问题可能已经消失（第一点），或者现在有更好的方法来处理问题。