请教：SEAM中如何分层？
 |
zw80724
2008-09-08
最近我们的项目打算使用新的框架，所以研究了一下SEAM，让人比较困惑的一点是，SEAM提供的例子里面都是直接在action中访问entity manager，eql也直接写在action代码里面。以前习惯的action，service，dao的分层方式在SEAM里面还合适使用吗？如果都是按例子中的方式写代码，一旦有比较复杂的业务逻辑，会让action很庞杂，同时本来可以复用的数据访问代码散落在action各处。前几天跟一个用SEAM做过项目的朋友交流，他说他们以前也做了dao分层，但是是基于领域模型的，估计是那种“充血”模式的，但是个人不太喜欢这种风格。不知道各位在项目里面是怎么样使用SEAM的？
|
|
little51
2008-09-08
seam好像并不鼓励过多的分层。
参考seam自带的例子booking，比如注册，调的是<h:commandButton id="register" value="Register" action="#{register.register}"/> ,register是个EJB的@Local接口，真正的实现是在RegisterAction中。我想他的方法可能是action->interface->真正的实现。 不知分析的有无道理，不过与您的问题不对题，权作为讨论吧。 |
|
zw80724
2008-09-10
哎，讨论的人比较少。。。
To：little51 是的，seam里面的例子都是那样写的，业务代码都写在RegisterAction 这个Bean中，但这样不做任何分层，会不会让这个session bean很大，难于维护，而且数据库访问的部分代码也不能复用。 SEAM的思想的确非常好，但不知道用的人到底多不多，现在在项目中使用会不会太冒进了。 |
 |
SSailYang
2008-09-10
Seam 并不对使用者的架构分层设计做限制。只是由于 Seam 中大部分例子比较简单，所以分层也比较简单。你可以看看 wiki 这个例子，这个是比较复杂的。
Seam 的使用是很灵活的，同样分层也能很灵活。用于技术的不同，分层肯定会比以往有不同。不要用 SSH 的分层方式套就是了。 简单说来，Seam 中的 Action 可以看作是细粒度的 SSH 中的 Service 有状态的 Session Bean 不要弄得很大 |
 |
afadgaeg
2008-09-10
分层主要是为了复用和扩展，如果你的业务方法永远也不会被第二个业务调用，那还分什么层
orm那么简单明了，事务又交给容器了，不分dao也没什么 粒度要自己判断，几层几层只是参考 |
 |
fireflyc
2008-09-11
算了，本来打算写到Blog上赚点流量之类的。（绝非商业目的，只是blog太冷清了。）看来要提前公开了。
其实seam是要分层的，我们考察一下seam例子的做法，它们大部分都是直接在action中做的持久化操作，比如保存数据，查找数据。这种做法累死与Asp.net，是典型的组件行web框架的做法。 好处是显而易见的，就像我们做桌面开发一样；拖放控件，写代码。也就是事件驱动的概念。 坏处也是显而易见的，代码膨胀的时候action会越来越胖最后所有的逻辑没有了。想一下我们在做桌面开发的时候是如何解决的？我们会封装函数，函数不行我们直接就开始封装对象，然后在事件里面调用。 上面说道asp.net的做法也是如此，但是这种做法是asp.net不推荐的，除非是为了做一些简单的东西。在asp.net开发中也是提倡分层的。他们会分出一个service层，更有甚者分出了DAO层，和java ee的做法一模一样的。 对于seam来说由于我们采用的是JPA所以没有必要存在DAO了，而且如果我们用DAO做封装会发现大部分的DAO的代码是几乎没有的，只是一个空壳。所以建议只有一个service层就足够了。然后在action中调用。 具体做法如下 model service action 就这三种主要的对象。 |
 |
isky
2008-09-11
seam的controller 用的jsf 他是事件驱动 和以前struts webwork 是不一样的 他们是请求驱动的
|
|
zw80724
2008-09-11
看了大家的讨论，觉得受益匪浅，大家也可以看看Robbin发的这个帖子的讨论也能学到很多东西：http://www.iteye.com/topic/212105
SEAM的确是在简化web应用开发的分层，Gavin King提出的WebBeans的目的也就是让SessionBean能作为JSF的受管bean，这也就是我们现在seam中看到的action，那既然是SessionBean（当然SEAM也支持POJO），应该就是处理业务逻辑的，从而可以看成是传统三层架构中的service层，这点上我比较同意 SSailYang 的观点。从SEAM下面的代码可以看出，action中根本不处理req，res和页面流转这些东西，seam的action完全是业务逻辑所在。 那么意思就是说，seam下面的代码没有必要讨论传统的action与service的分层界线了，也可以说seam帮开发人员省略掉了传统的action层。 OK，那么现在就剩下service和领域模型了，站在seam的角度就是action与entity bean了，那么复杂的企业应用的业务逻辑会不会让action很复杂，有没有必要让CRUD操作抽取到DAO层中去呢？个人觉得DAO的抽取应该是能增加一些复用的，由于没有动手试过，不知道会不会反而成为画蛇添足的一举呢？ |
|
little51
2008-09-11
zw80724 说的有道理
|
|
terranhao
2008-09-11
通常可以将
<h:commandButton id="register" value="Register" action=" {register.register}"/> register.register方法其实就可以看做一个controller,在这个方法里再调用相关的sessionbean来实现业务逻辑。 |
