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 分层去设计。

1. 持久层 DAO
   在 Seam 中，可以完全忽略持久层 DAO，在业务逻辑中直接进行实体管理。这样做的好处是开发可以 更方便、更高效，坏处是重用少、难维护。特别是在这个开源项目中，分布式的团队协作，优秀的设计 可以让每个开发人员都更好的理解系统。结合 Seam 提供给我们的优势，决定给常用的实体提供 DAO。
2. View 与组件
   由于在 View 层可以使用 EL 直接调用某个 Seam 组件，所以会存在在各个层次中组件都可以在
   View 中被使用。这样做可能会导致混乱，是否应该建立一个 Facade 层来提供 View 需要的 组件呢？但是这样做将会大大复杂整个系统的设计，尤其是将 Seam 提倡的快速开发思想完全抛弃。当然，好处就是 View 开发人员可以不用了解太多的逻辑组件，直接使用 Facade 层里提供的组件。

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

二. Seam 与 JSF 2.0

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