Java 6设计模式

Question

我想知道Java 6实现中可以应用的设计模式。

• MVC.
• GOF.
• DAO
• Persistent关系mapping
• Pooling
• CEC
• Entity控制边界(ECB)
• 和许多其他

JPA是否消除了DAO的使用？

请提供其他可以学习的模式。

Answer 1

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

例如，使用注入而不是ServiceLocator。

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

GOF模式仍然是必需的，因为它们(仅)与Java无关。

一般来说:模式有一个意图:他们希望为一个问题生成一个解决方案/最佳实践，其中包含一组由环境提供的功能(在您的例子中: Java，Java 6，.)

如果问题已经解决:如果您不再需要模式了--如果由于模式的喜好环境发生了变化，您不再需要模式，那么您必须重新考虑模式，因为可能问题已经解决了(第一点)，或者现在有了更好的解决问题的方法。

Answer 2

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

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

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

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

here的辩论有一个很好的总结。最好的答案是，这取决于。如果您的应用程序很复杂，而且在某些情况下您可能直接访问JDBC (因为JPA和ORM工具不是所有问题的答案，而且在某些方面非常糟糕)，或者如果您需要从与ORM不兼容的源中提取数据，那么无论如何您都需要一个DAO层，所以在我看来，我宁愿一致地使用DAO层来处理所有事情。它通常没有那么复杂，它将您的业务逻辑与持久化逻辑隔离开来，我认为这是一件好事。但是，这是个人喜好的问题，如果你的应用程序是适当的简单，它可能是过头了。

对于可以与JPA here一起使用的通用DAO模式，有一个很好的建议。这允许您使用DAO的好处，因为您始终可以针对特定的DAO重写它，同时保持更标准和更典型的数据库交互更简单。