直接通过 servlet 调用数据库与使用 EAO 和 EJB 中介调用数据库
我通过 servlet 在网页上显示文本和 xml。 servlet 只是在加载时通过调用 getPost() 方法将 HTML/XML 加载到页面。现在我已经按照我想要的方式工作了，下一步是用对数据库的调用替换静态显示文本，以便它可以动态显示信息。我的问题是：
最好的方法是什么？我使用 JPA 和实体进行持久化，但我可以选择直接调用持久化项目或通过我创建的数据/实体访问对象。我遵循了一个教程，该教程使用 EAO 和带有 EJB 的实体作为教授最佳实践的方式。然而，我还没有看到这样做的价值。当我可以直接访问数据时，通过 3 个类似乎过于复杂。
那么这是首选方法吗？或者servlet 应该直接访问数据还是通过EAO 访问数据？
谢谢
I'm displaying text and xml on a webpage through a servlet. The servlet just loads the HTML/XML to the page on load through calls in the getPost() method. Now that I have that working the way I want it to my next step is to replace the static display text with calls to the database so that it can display information dynamically. My question is:
What is the best way to do this. I'm using JPA and entities for persistence but I have a choice of making direct calls to the persisted items or going through an Data/Entity Access Object which I have created. I followed a tutorial that used EAO's and Entities with EJBs as a way of teaching best practices. I don't see the value in doing this yet, however. It seems overly complicated to go through 3 classes when I could just access the data directly.
So is this the preferred method? or should servlets access data directly or through EAO's?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果你不需要它——就不要这样做。
不要无缘无故地引入额外的抽象层。它只是更难维护，如果你真的不需要它 - 你将以一堆死代码（空委托）结束。
因此，如果我是您，我会做的第一步是使用 JPA 作为持久层。它将让您摆脱额外的 DAO 类。 EntityManager（您可以将其视为 JPA 的入口点）本身就是一个数据访问对象。
您的 servlet 代码不应直接依赖于数据库，因此 EntityManager 在您的情况下是一个很好的关注点分离。
然后您可以考虑将表示代码（Servlet）与面向数据的操作分开。您可以通过使用 CDI 并在简单的 POJO 中实现此逻辑来做到这一点。这将使您（Servlet）不依赖于用于获取或转换数据的代码。您的 servlet 通常只是“获取数据”（它不必知道数据来自哪里）。
如果您需要 EJB 引入的服务（事务性、线程安全性、计时器、异步调用、附加入口点，如 SOAP 或 REST Web 服务、JMX 访问、池化等），请使用 EJB。
HTH。
If you don't need it - don't do it.
Don't introduce additional abstraction layer without a reason. It's just harder to maintain, and if you don't really need it - you'll end with a bunch of dead code (empty delegates).
So, the first step I would do if I were you, I would use the JPA as a persistence layer. It will let you get rid of your additional DAO classes. The EntityManager (you can think of it as an entry point to the JPA) is a Data Access Object itself.
Your servlets code should not depend on the database directly, so an EntityManager is a great separation of concerns in your case.
Then you can think of separating your presentation code (Servlet) from the Data-oriented operations. You could do that by using i.e. a CDI and implementing this logic in simple POJOs. This will let you (Servlet) not to depend on the code used for fetching or transformation of your data. Your servlet will typically just 'get the data' (it doesn't have to know where from it come).
Use EJBs if you need services they introduce (transactionality, thread-safety, timers, asynchronous calls, additional entry-points like SOAP or REST Web Services, JMX access, pooling, ...).
HTH.
有不同的因素，了解这两种方法很有用。
EJB 更简单，并且具有许多事务管理功能。如果没有 EJB，持久化的代码将会更加冗长。
也许这将有助于更好地理解。
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
There are different factors, it is useful to know both approaches.
EJB's are simpler and have a lot of features for transaction management. Without EJB the code to persist would be more verbose.
Maybe this will help to understand better.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
是否使用 DAO 应该在每个用例的基本 IMO 中完成。
点击一个答案的链接可以帮助您解决这个问题。
EntityManager应该如何很好地解耦服务层和数据访问层？
Whether or not use DAOs should be done in a per use case basic IMO.
Following a link to an answer that could help you figuring this one out.
How should EntityManager be used in a nicely decoupled service layer and data access layer?