Review in Seam

    最近用休息之余看了《seam in action》和一些项目相关资料，总感觉我们的项目除了在代码质量上的问题外，还存在很多对于框架理解性的偏差，所以在很多细节的处理上都显得十分的盲目。我总结了下面的几个方面，与其说是我对项目现状的质疑，不如说我对于Seam和项目存在的一些疑问。

     第一.项目是否有必要使用EJB

     1.JavaBean是可以handle现有项目中所有的逻辑的，项目规模小不存在分布式的需求，引入EJB，相当于引入额外的复杂性；

     2.Ear的项目打包格式，不提供EJB组件和JavaBean的热部署，让程序员的调试开发效率大打折扣；

     3.Hibernate可以替代Entity bean，同样可以搭配JPA共同使用。

     第二、项目应该尽量使用Seam的组件（尤其是UI组件），代替JSF组件。

     1.相对于JSF组件，Seam的UI组件并不是简单对JSF在语法格式上的优化，Seam对JSF的改进是体现在处理Request的风格上，应该说是从本质上在改变JSF中“一切皆post”的处理风格。可以说，在Seam的项目中尽量使用SeamUI组件，是对Seam处理Request风格的一种肯定，而Seam的这种风格与Seam提倡的Conversation等等的特性是一脉传承的，所以说只有只有完全使用好Seam UI组件，才能有内及外的写出纯正的Seam应用；

     2.貌似应该避免<h:commandButton>与commandLink，取而代之的是<S:link>和<s:button>，理由就是避免JSF中的submit form 方式的request；

     3.<DataModel>和<DataModelSelected>标签取代<f:Datatable>（标签的具体拼写我记不清了），Seam的datamodel提供了action中数据集的注出，以及数据集中被选择的行数据向Action中的注入，从而省略了JSF中datatable与backbean的绑定操作。

     4.<s:decorator>和richface，a4j等标签的标准化使用，这是强调页面是否为Seamful的，使用时最关键的保证页面标签使用的统一性与规范性。这才便于提高团队开发中代码的可读性。

       第三、Conversation的用法，Conversation的使用归根结底在于Seam中对于组件状态的管理。

      1.记得文档中提倡，不要将Entity bean作为组件维护在各个作用域中，取而代之的方式是，将Entity bean作为某个Action的属性，由Action将其注出到某个作用域，或者干脆就和此Action的作用域保持同步；

      2.明确每个Action的分工，不要将两件不相关的事（由同时需要状态）放在一个Action中去处理，这样这个Action就会维护过多的状态；

      3.Conversation的begin和end，是可以放在*.page.xml，然后通过页面流去维护的，这也是文档中比较强调（推荐？）的一种方式；

      4.状态作用域的正确使用，是可以避免boring的用隐藏域进行页面之间的传参的；

      5.JBPM is necessary；

      6.理解并正确使用start、join、end的用法

       第四、开发中重中之重的问题

      1.热部署

      2.debug

      3.Seam中代码的自动生成，而不是copy、paste

      4.Testng下的单元以及集成测试。

      以上，就是最近反思的一些感想，希望在以下的时间里能够更深入的总结下Seam的东西。