Java Seam应用程序体系结构

我需要在Seam中实现相当大的系统。我正在考虑建筑的设计方法。如果使用页面控制器、应用程序控制器、前端控制器或它们中的每一个都是好的。如果使用后端bean是有帮助的，或者可能没有必要这样做。如果您有任何建议或链接到有用的文章，我将不胜感激

非常感谢

---

丹尼尔·米库奇（Daniel Mikucki）

如果你需要为一个项目学习很多关于Seam的知识，我建议你去买这本书，这是这方面最好的

为了回答您的问题，我个人更喜欢在Seam中使用pull MVC样式，在这里您引用视图模板中的数据，Seam根据需要使用

@Factory

方法进行初始化。然而，在Seam中有不止一种方法可以做到这一点，因此值得先阅读关于替代方案的内容，因此推荐这本书

或者，先构建几个Seam应用程序，然后再尝试构建一个“正确的”：）Daniel

使用前端控制器是一种很好的做法，大多数人都不知道这种设计模式

这是一个非常好的设计模式，因为它可以确保您通过单个入口点访问应用程序。您可以用更少的配置轻松监控所有的东西。您可以减少可能的代码重复量，因为只有一个入口点。除了要维护的代码更少之外，代码应该更容易遵循，因为只有一种方法可以使用。然后，您可以轻松地遵循应用程序的执行流程

不幸的是，Seam并没有真正的前端控制器模式。我没有花那么多的时间来开发自己的系统，但是安全性和审计能力是我的首要关注点

就页面/应用程序控制器而言，在Seam中，您有更多的上下文或范围可用。事件、页面、会话、会话、应用程序等等

如果您正在开发一个控制器，或者在Seam中开发一个页面操作，大多数情况下，它都是基于事件的。这是寿命最短的范围。如果您有页面流，那么您将使用会话范围的组件

看看源代码中的示例。你可以用很少的代码做很多事情，这是令人惊讶的，但同时，有很多事情可能需要一段时间才能了解

大多数地方采用的n层设计不一定适用于这里。对于我的大多数页面，我定义了一个将在XML中使用的查询（实体查询），然后将其注入到我的页面操作中并在那里调用它。因此，不需要控制器、服务、dao和实体类，而只需要一个页面操作、查询和实体类。在大多数情况下，您可以删除服务层和dao层

您对服务的整个定义也可能会改变。对我来说，服务是一个服务提供者，比如通知、安全（审计）、异常处理等。所有这些服务都在后台运行，并且不与特定的http请求绑定

沃尔特

丹尼尔

我每个页面使用一个控制器，每个实体使用一个服务和一个dao

• 用例逻辑进入控制器
• 实体服务中包含特定于实体的业务逻辑
• 跨多个实体的操作您可以创建门面服务—位于控制器和实体服务之间的服务

虽然上述方法是一种很好且实用的方法，但理想情况下：

• 您可以将控制器中的任何非MVC代码分解为它自己的服务类，即每页1个服务类
• 您应该只通过实体服务访问实体dao

下面是控件的流程：

理想情况下： 用户界面 ->PageController.java ->PageService.java ->EntityService.java ->EntityDao.java

实际上，您可以减少几层： UI->PageController.java->EntityService.java

或对于涉及多个实体的操作： UI->PageController.java->Facade.java->Entity1Service.java，Entity2Service.java

PageController.java将是Seam@组件，在您的ui中，您可以将其称为：

#{pageController}

并从视图中提取数据

在体系结构中，最重要的是如何在堆栈中分层，以避免层之间的循环依赖。例如，实体服务不应该引用控制器等等

另一件重要的事情是在整个应用程序中保持分层的一致性。如果可以使用代码生成器在整个应用程序中保持代码的一致性，那么对于大型项目来说，这确实是值得的。查看您是否对代码生成感兴趣（Clickframes为Seam应用程序生成启动代码，并提供完整的JPA/valdiation/security支持，然后您可以对其进行修改）。如果感兴趣，请使用Clickframes查看此构建