Seam 敏捷开发与 JavaEE 经典分层架构

Seam 敏捷开发与 JavaEE 经典分层架构

转载请保留作者信息：

Author: 88250

Blog: http:/blog.csdn.net/DL88250

MSN & Gmail & QQ: DL88250@gmail.com 本文简要讨论了两个问题：Seam 与经典 JavaEE 分层架构的联系与问题；Seam 与 JSF 2.0 规范。这是一个系列的文章，将讨论 Seam 框架用于实际开发的种种问题。

一、Seam 敏捷开发与 JavaEE 经典分层架构

在 Seam 中由于双向注射(Binjection)的机制，允许我们可以减少层次的划分，简化设计、开发的复杂度。这也 Seam 框架的目标之一。不过，由于结合本项目的特征（开源、规模较大），我决定还是基于经典的 JavaEE 分层去设计。[b][/b]

[b][b][b]持久层 DAO

[/b][/b][/b]在
Seam 中，可以完全忽略持久层 DAO，在业务逻辑中直接进行实体管理。这样做的好处是开发可以
更方便、更高效，坏处是重用少、难维护。特别是在这个开源项目中，分布式的团队协作，优秀的设计 可以让每个开发人员都更好的理解系统。结合 Seam
提供给我们的优势，决定给常用的实体提供 DAO。

[b][b][b]View 与组件

[/b][/b][/b]由于在 View 层可以使用 EL 直接调用某个 Seam 组件，所以会存在在各个层次中组件都可以在

View 中被使用。这样做可能会导致混乱，是否应该建立一个 Facade 层来提供 View 需要的
组件呢？但是这样做将会大大复杂整个系统的设计，尤其是将 Seam 提倡的快速开发思想完全抛弃。当然，好处就是 View
开发人员可以不用了解太多的逻辑组件，直接使用 Facade 层里提供的组件。

[b][/b]综合分析后，我觉得关于 DAO 是需要的，但
Facade 模式不应该放到基于 Seam 框架的设计中。原因就是 Seam 已经把 View 和逻辑“粘合得”很紧密了，我们不应该放弃
Seam 带给我们的优势。View 与业务逻辑 实现之间的接口无论如何都是要定义的，不应该为了一时方便而使用 Facade
模式。所以，Facade 模式的适用场景还需要进行深入思考和实践。[b][b][/b][/b]

[b][b][b]
二. Seam 与 JSF 2.0[/b][/b][/b]

[b][b][/b][/b]当
前，JSF 2.0 的实现已经可以使用了，不过 Seam 还是只支持 JSF 1.2。JSF 2.0 中增强了 AJAX、默认使用
Facelets 作为视图定义，还有一系列的新 JSF 组件与修改。这将对现有的一些 JSF
实现(RichFaces、MyFaces等)造成很大冲击。不过这个也是没有办法的，现在该项目已经在开发中了，等JSF 2.0 正式
Release 的时候 Seam 应该会提供解决方案。[b][b][/b][/b]