对于以下解决方案，您会建议一个好的，实用但简单的模式：
是否有必要使用自己的DAO层来保持持久性？我使用JPA将对象持久保存到我的数据库中。
我应该从EJB中撤销业务逻辑吗？所有在线消息来源都告诉我不同的事情，让我感到困惑......
答案 0 :(得分：5)
我肯定会将业务逻辑放在无状态会话Bean中。无状态会话bean很好，因为它们可以很好地捕获事务边界。它将View层与持久层分离。
注意SSB的方法符合用户想要实现的小企业目标。
另一点是，您必须确保您返回的数据包含对象树中的所有数据，并且您不依赖延迟加载来获取其余数据，因为这会导致所有类型的问题。
尽可能远离有状态会话Bean：它们是坏消息，在Web应用程序环境中是一个破碎的概念。
对于长时间运行的东西，请考虑使用通过发送JMS消息触发的Message Driven Beans。这些是进行后台处理的好方法，可以更快地释放业务逻辑，缩短事务处理速度并更快地将控制权交还给最终用户。
答案 1 :(得分：5)
对于使用JSP / Servlets + EJB + MySQL的解决方案，您会建议一个好的，实用但简单的模式
使用您选择的MVC框架，无状态会话Bean用于业务逻辑和事务管理（如果您不需要远程处理，则更喜欢本地接口），持久性实体。
尽可能地注入EJB（如果您使用的是Java EE 6，这意味着在任何地方，您也可以跳过该界面。）
是否有必要使用自己的DAO层来保持持久性？我使用JPA将对象持久化到我的数据库。
有些人可能会说是，我在大多数情况下都说不。 EntityManager已经实现了Domain Store模式，没有必要为了简单需求而将其屏蔽在DAO后面。
您可能需要阅读以下资源以获取更多有关此内容的意见：
我应该从EJB中撤销业务逻辑吗？
我不会。将您的业务逻辑放在您的（无状态）会话Bean中。 EJB3是POJO，它们很容易测试，不需要将业务逻辑委托给另一层。
答案 2 :(得分：1)
Anno 2012我不建议将Servlet和JSP作为表示层。这在2002年风靡一时，但那是十年前的事了。
今天，Java EE有一个名为JSF的优秀MVC框架。你改善使用它会好得多。你很可能想从组件库PrimeFaces中获取一些Widgets，因为所有标准的Widgets都有点基础。像OmniFaces这样的实用程序库也是一个很好的补充。
关于DAO;不要直接使用（JSF）支持bean中的实体管理器，但如果您已经在为业务逻辑使用Service类（事务边界），那么使用DAO可能会有点过分。
DAO还有一些小优点，比如dao.findByName（...）看起来比加载命名查询，设置参数和获得（单个）结果更清晰，但成本是你必须为每个实体维护一个单独的DAO，可能除了一些服务之外。