JavaEE6（EJB、JSF、CDI、JPA）应用程序的设计决策

我正在开发一个小的（但不断增长的）JavaEE项目，它基于部署在JBossAS7.1Beta1上的EJB3.1、JSF2、CDI（WELD）和JPA2技术

作为起点，我创建了一个基于Knappsack Maven原型的Maven项目

我的架构基本上与原型提供的架构相同，随着我的项目的发展，我认为这个原型似乎已经达到了极限。我想根据我的需要修改原型的基本思想。但首先让我解释一下目前项目是如何组织的

整个项目是围绕Seam式的家庭课程构建的。视图正在引用它们（通过xhtml模板中的EL）。大多数主类是

@Named

和

@RequestScoped

（或简称

@Model

）或

@ConversationScoped

，Entripse Java bean是

@Inject

ed。基本上，这些（通常

@Local

）EJB负责数据库访问（某种DAO）获取容器自动管理的事务。因此，每个DAO类都有自己的CDI注入。目前，每个DAO都集成了逻辑上相互属于的方面（例如，原型中有一个

学校DAO

，负责创建

教师

s、

学生

s和

课程

s）

这当然会导致DAO的不断增长，DAO没有明确定义的任务，并且变得难以维护和理解。作为一种痛苦的副作用，重复代码的风险也在增加

因此，我想通过只使用负责一个特定任务的DAO（a

@StudentDao

、a

@TeacherDao

等等）来打破这种设计。现在我有麻烦了。由于每个DAO都有一个对自己的

EntityManager

的引用，因此不能保证下面这样的东西会起作用（我认为它永远不会起作用：）

JPA实现抱怨列

课程.TEACHER\u ID

的值为

null

（假设

课程

与

教师

的FK关系不可为null）。每个DAO都有自己的

实体管理器

，

教师

由

教师DAO

中的一个管理，但

课程DAO

中的另一个试图合并

课程

<实体

也许我使用的archetye不适合更大的应用。但是，如果我使用的技术是强制性的（EJB3.1用于容器管理的事务[以及后来的其他业务相关的东西]、JSF作为view technologie、JPA作为数据库映射器和CDI作为“必须拥有的，因为它很时髦：”），那么对于这样的应用程序来说，什么才是合适的设计呢

编辑：

---

我现在在所有其他DAO类继承的基类中注入了一个

EntityManager

。所以所有DAO都使用相同的实例（调试器显示相同的对象id），但我仍然存在一个问题，即我从数据库中读取的所有实体都会立即分离。这让我感到奇怪，因为这意味着要么没有容器管理的事务，要么在读取实体后事务立即关闭。每个DAO都是一个无状态的EJB。它们被注入到我的JSF bean（

@Named

和

@RequestScoped

）中，我希望从这里使用CRUD操作。我错过了什么吗？

让每个DOA都有自己的

实体管理器是一个非常糟糕的设计

每个事务/请求都应该有一个
EntityManager
，并将其传递给每个DOA，或者让他们共享同一个或从上下文中获取它。
让每个DOA都有自己的
EntityManager
是一个非常糟糕的设计

每个事务/请求都应该有一个
EntityManager
，并将其传递给每个DOA，或者让它们共享同一个或从上下文中获取它。
我现在在所有其他DAO类继承的基类中注入了一个
EntityManager
。所以所有DAO都使用相同的实例（调试器显示相同的对象id），但我仍然存在一个问题，即我从数据库中读取的所有实体都会立即分离。请参阅编辑后的问题…我现在在所有其他DAO类继承的基类中注入了一个
EntityManager
。所以所有DAO都使用相同的实例（调试器显示相同的对象id），但我仍然存在一个问题，即我从数据库中读取的所有实体都会立即分离。请参阅编辑的问题。。。
Teacher teacher = teacherDao.find(teacherId);
course.setTeacher(teacher);
courseDao.save(course);