4

您会建议什么作为解决方案的一个好的、实用但简单的模式：

  • HTML + JSP（作为视图/演示）
  • Servlet（控制器、请求、会话处理）
  • EJB（持久性，业务逻辑）
  • 数据库

是否有必要使用自己的 DAO 层进行持久化？我使用 JPA 将对象持久保存到我的数据库中。

我应该从我的 EJB 中撤回业务逻辑吗？所有在线资源都告诉我不同​​的事情并使我感到困惑......

4

3 回答 3

5

我肯定会将业务逻辑放在无状态会话 Bean 中。无状态会话 bean 很好，因为它们很好地捕获了事务边界。并将 View 层与持久层分离。

注意 SSB 的方法与用户想要实现的小型业务目标相对应。

另一点是，您必须确保返回的数据包含对象树中的所有数据，并且您不依赖延迟加载来获取其余数据，因为这会导致各种问题。

尽可能远离 Stateful Session Bean：它们是个坏消息，并且在 Web 应用程序的上下文中是一个错误的概念。

对于长期运行的事情，请考虑使用通过发送 JMS 消息触发的消息驱动 Bean。这些是进行后台处理的好方法，它可以更快地释放业务逻辑，使事务更短，并更快地将控制权返回给最终用户。

于 2010-06-03T22:13:15.287 回答
5

对于使用 JSP/Servlets + EJB + MySQL 的解决方案，您会建议什么作为一个好的、实用但简单的模式

使用您选择的 MVC 框架，Stateless Session Beans 用于业务逻辑和事务管理（如果您不需要远程处理，则首选本地接口），Entities 用于持久性。

尽可能地注入您的 EJB（如果您使用的是 Java EE 6，这意味着在任何地方，您也可以跳过该接口）。

是否有必要使用自己的 DAO 层进行持久化？我使用 JPA 将对象持久保存到我的数据库中。

有些人可能会说是，我在大多数情况下都说不。EntityManager已经实现了Domain Store模式，不需要为了简单的需求而将其屏蔽在 DAO 后面。

您可能需要阅读以下资源以获得更多关于此的意见：

我应该从我的 EJB 中撤回业务逻辑吗？

我不会。将您的业务逻辑放在您的（无状态）会话 Bean 中。EJB3 是 POJO，它们易于测试，无需将业务逻辑委托给另一层。

于 2010-06-03T23:38:53.170 回答
1

Anno 2012 我不建议使用 Servlets 和 JSP 作为表示层。这在 2002 年风靡一时，但那是十年前的事了。

今天，Java EE 有一个优秀的 MVC 框架，称为 JSF。你最好改用这个。您很可能希望从组件库 PrimeFaces 中获取一些小部件，因为所有标准部件都有点基础。像 OmniFaces 这样的实用程序库也是一个很好的补充。

关于 DAO；不要直接在 (JSF) 支持 bean 中使用实体管理器，但如果您已经在业务逻辑中使用服务类（事务边界），那么使用 DAO 也可能是矫枉过正。

DAO 仍有一些小的优点，例如 dao.findByName(...) 看起来比加载命名查询、设置参数和获取（单个）结果要清晰一些，但代价是您必须可能除了一些服务之外，为每个实体维护一个单独的 DAO。

于 2012-11-26T09:35:36.723 回答