J2ee架构大讨论：每一层到底实现些什么功能？

如果你用JSP直接访问数据库都能满足需求，说明你们的业务根本不需要EJB提供的分布能力，那你的确不应该用EJB。

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

其实我们如果用jsp直接访问数据库的方式，根本不存在这些问题。哪这样的结构给我们带来的好处到底是什么？
=================================================================================
任何分层模型，不管是osi7层模型还是j2ee,都是为了将复杂问题的结构简单化。分层带来的好处就是使代码的结构易于理解，还有就是可移植性，设想你要把应用从jsp移植到applet或应用程序那连接访问数据库不是要重写？不过小规模的用例的确可以在jsp里完成一切。j2ee本来就是分布计算的，他把重量级的应用分布在不同的层。轻量级的jsp就可以了。
比如没有dao这层，你原来使用db2，现在改成oracle了，如果你直接在jsp上访问数据库，那你整个页面都要修改了。否则只需要增加一个新的dao的实现，view层根本不需要改动。这就是分层的好处。尤其在开发一个大个系统。
大家告诉我这两个case该怎么解决好不好
对于第1个问题：
两种验证分开做，
数据长度、字符限制、数据类型的验证放在客户端做；
业务验证放在sessionBean中做，验证通过后在使用ENTITYBEAN，否则不使用。对于第2个问题：
多表联查的功能不使用ENTITYBEAN,设计一个专用的SESSIONBEAN封装查询结果来解决这个问题。
（分层结构中，数据库访问层应由entityBean和专用于实现多表对应的SESSIONBEAN来完成。）
另外，CMP和BMP的概念是针对持久性管理的方式而言，与多表联查等没有直接关系。ENTITY BEAN设计的一个注意事项是：
BMP尽量不用，CMP不要用于涉及大数据量查询的业务中。
一是对数据长度、字符限制、数据类型这样的验证
----------------------------------------------------
这个完全可以在jsp直接实现。js完全具备此能力。一是通过业务规则来进行验证
--------------------------
既然楼主想到了struts，这个验证完全可以放到Action里面啊。2.用户要输入一个条件来进行对多个表进行联查，查询的结果包括多个表的内容，要进行分组，还要进行分页.
---------------------
对于复杂的查询操作，我觉得cmp实现起来就不是太好了。bmp可以考虑。jdbc直连也不失一种好的解决方法。
>>1.用户要向数据库中写一条记录
>>2.用户要输入一个条件来进行对多个表进行联查，查询的结果包括多个表的内容，要进行分组，还要进行分页.我告诉你该怎么解决。你应该给你的用户装个支持多种JDBC驱动的数据库客户端，或者用Delphi的数据库控件做个数据表查看器。你不就是要让用户操作数据库吗？哪里需要做什么Java程序？你这不叫需求，你这叫设计，而且是想当然的设计。只不过是你觉得用户做这样的操作就可以了，但是你的用户究竟是要做什么事？要实现什么业务目的？达到这个目的有没有更好的做法？现在的这种做法以后会不会改变？你现在就一相情愿地认为用户只需要并且永远只需要这两个数据库操作，那你直接给他装一个Oracle客户端好了。
Schlemiel(维特根斯坦的扇子) ，真是晕。可能我没有说清我的问题，我只是举了两个例子，让大家讨论一下如果使用j2ee的框架，像这样的功能在几个层之间是怎么样协作完成的。我并没有说这是需求啊。

yabbi21(yabbi21)，谢谢你啊。第一个问题，我也是这样想。但是第二个问题，是不是可以考虑用bmp来处理啊，还有就是大量的数据一般cache在哪一层啊？
感觉java版的朋友不多啊，如果这个问题在.net版上，至少也有二三十号人回帖啊
这样的功能不需要几个层，在JSP访问数据库就够了。既没有业务需求也没有性能需求，那就不用什么分层，任何设计都是多余的。
我怎么感觉struts又臭又长啊!
比如修改条记录，要写两个jsp文件，两个action.
先通过editAction把要修改的数据加载到actionFrom中,然后通过jsp显示，然后用户提交后又通过saveAction把写回数据库，完了又要把修改成功的消息放到下一个jsp中。
为了完成这样的功能，还要写一些助手bean。
真是晕，大家是不是这么用的啊？
如果你用JSP直接访问数据库都能满足需求，说明你们的业务根本不需要EJB提供的分布能力，那你的确不应该用EJB。
………………………………………………………………………………精
如果业务不复杂，项目比较小，真的没必要用struts了。否则确如楼主所说增加代码量，还需要配置。当时如果项目比较大，逻辑比较复杂，还是用struts比较好，分层清楚，jsp的交互全在xml里实现了。
bon_jovi(西门疯雪) ：如果项目比较小，应该使用Struts，使用Struts的目的是使层次清晰，偏于扩展维护；
中小的项目中使用EJB是不必要的，即不能使开发简单，又影响性能。如果是大型项目，EJB是不错的选择（充分利用应用服务器的功能是复杂问题简单化）。
如果基于Struts来做大型项目，那么系统架构本身的实现时就会很复杂化，比如并发事务控制策略，大型数据对象的生命周期，多数据库的连接，连接池优化等，这些问题的实现必要性，工数等必须考虑。
to yabbi21(yabbi21)：
struts和EJB有关系吗？
Schlemiel(维特根斯坦的扇子) :二者当然没有关系，我只是说在为系统选择架构上，
如果是中小型的应用，那么根本就不需要使用ejb来开发。
这样子的构架做个DEMO到是很不错。；）
构架也是由需求而来的：）关键在于理解需求后到构架的转化：）
这是个分层的问题,两个例子1 httprequest 直接到 sql语句2 httprequest - action form - vo - dao多一层,就多一次灵活变化的机会