在view层把request当作参数给model层啊。model层想用什么就用什么数据啊！然后model层需要调用dao层的时候我也是传这个request阿。dao层想用什么就用什么数据啊
我觉得这样也没什么啊。。可是项目经理说不符合三层的结构。。其实我觉得也没什么不符合的挺迷惑的。三层不就是一种开发的方式吗？层次分开。要是非要
把request过滤成结构体之类的vo当参数传给dao层感觉也没有什么意义！还弄什么vo 、bo的不知道饶这么多干什么！
说什么彻底分开各个部分能单独跑。。但是一个web应用怎么可能单独分开啊分开还有什么意思
我觉得这样也没什么啊。。可是项目经理说不符合三层的结构。。其实我觉得也没什么不符合的挺迷惑的。三层不就是一种开发的方式吗？层次分开。要是非要
把request过滤成结构体之类的vo当参数传给dao层感觉也没有什么意义！还弄什么vo 、bo的不知道饶这么多干什么！
说什么彻底分开各个部分能单独跑。。但是一个web应用怎么可能单独分开啊分开还有什么意思
要set好半天.....
然后在传这个实体bean.
如果是request 的话直接传就好了...你说哪个麻烦?
首先你要把request数据解析出来放实体bean!数据多的话..
要set好半天.....
然后在传这个实体bean.
如果是request 的话直接传就好了...你说哪个麻烦?
一看就知道你没有开发经验。。
如果你不用实体bean的话。那么你就传request的话。那你还要model这个层干什么。直接传到持久层就行了么
view层提交后 control层把数据封装到对应的model层 后面调用相应的
model组件返回给view层lz看看mvc结构
就清楚了
不过我们应该更注重它的更大的优势，可能没在你的项目中体现出来
以上，也不知道说得对不对，大家一起讨论
一般没什么别的事 我不用module
所以是vc 哈哈...bean:果实
作用:包裹类 对数据封装
存在场所:逻辑--module层 物理--jsp文件
好处:实现数据-显示的分离.所以完整实习MVC是良好的习惯.
vc固然可以解决问题.但没有MM.就不漂亮了...
==================
引用:For_suzhen(不懂装懂)
以上，也不知道说得对不对，大家一起讨论
BSLZ
是什么?
是鄙视楼主
接分嘿嘿
一看就知道你没有开发经验。。
如果你不用实体bean的话。那么你就传request的话。那你还要model这个层干什么。直接传到持久层就行了么===================================================================================无语了!我要model层而不直接传给持久层的原因是.1.这样程序的结构比较清楚.而且不是放在一起程序结构混乱...2.我在做框架的时候通过开发人员分别对我model dao层的继承我可以实现一些共通的设置和对连接和一些特定资源的控制!3.对开发人员容易规范他们的行为.就好比你一个大类可以分成很多小类一样只是为了结构和重用以及清晰方面的考虑啊!你并没有说出你用DBbean or VObean的好处..和必要性
=================================================================================
这跟三层也不矛盾啊我还是三层啊.!你说request跟db结构不同.你要重新包装一个bean来存放request的内容.然后用bean方便处理.那你还不如在处理的时候从request取出来呢..反正你包装的时候也要取一次啊我不知道说得对不对，比方说你有一个学生表，里面是学生的东西，这样你可以做一个Student的Bean，让其跟Db中的表结构是一样的，这样，request过滤成studentbean 的实体，跟服务器交互起来岂不是更简单，
===================================================================================Student的Bean 我不用这个..我直接返回一个arrayList或者其他Hashmap什么的不是一样吗 ?而且你可以让bean的生命周期可控，以后再用到直接调用
======================================================================
直接调用那里直接调用呢?。其实就是一种思想，既然楼主觉得request方便，完全可以抛弃mvc的思想阿。
不过我们应该更注重它的更大的优势，可能没在你的项目中体现出来
以上，也不知道说得对不对，大家一起讨论
=============================================
我不想抛弃mvc但是我看大家都在用结构体 或者dbbean vobean这种东西我觉得不是那么必要..我想知道这样用有什么好处啊
每一层负责每一层的任务，这样在测试，维护时也很方便。
request承载了太多深层次永不倒的东西，既然无用，就不应该传过去。
===========================================================
会出现什么问题
每一层负责每一层的任务，这样在测试，维护时也很方便。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
我同意这个我的问题是为什么要有类似vo bean这种东西啊
request承载了太多深层次永不倒的东西，既然无用，就不应该传过去。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
确实多写东西．可是考虑到不用在做结构体和来回过滤数值的原因．．
传request确实简单啊
而m模型层的代表Form对应着页面的内容，换句话说，页面上面有什么，Form里面就有什么和她对应，并且还负责reset和校验其中数据的正确等等
c控制层负责对数据的调度和控制，包括对Form的初始化，更新等等action对于web开发的人来说，你不觉得很熟悉吗?
先暂时这样理解好了，打字很累啊！！再看书理解一下
LZ定义了一个M层的体系结构，所有的其它程序员的实现的M层模块都要按此体系结构：一个M层的模块，它包含两部份。一个是它的数据模型，一个是它的业务逻辑模型(LZ所说的DAO层)。任何一个M层的模块选择一种简单的数据结构（比如ArrayList,hashmap）作为数据模型，而不同的M层模块可能使用不同的数据结构，并对其它的模块隐藏这一不同。业务逻辑模块除了有完成业务所必要的方法外，还实现了LZ定义的一组接口。这组接口可能用来接收来自C层的请求（这样C层可以支持所有的M层模块，由此来提高可重用性和灵活性），把数据模型中的数据写入DB，实现Observer pattern下的功能（包括LZ说的返回一个arraylist hashmap之类应该就是说这个吧）。
另一方面LZ说的“把request传给m层再传给dao层”之类的，按我的理解是表达上的问题，因为dao层就是上述M层的一接口（虽然LZ 貌似没把它写成接口，而写成类供别人继承，反正本质是一样的），所谓的dao层就是M层的一部份。没有所谓的"request再传到dao层"，request还是在M层中，只是由实现的所谓的dao层中定义的方法的模块（在LZ的实现中是继承了LZ所写的DAO的类）来处理数据模型和完成业务。
以上就是我对LZ所说的“model层想用什么就用什么数据啊！然后model层需要调用dao层的时候我也是传这个request阿。”关于bean,dbbean vobean是否需要要看据体的应用。按LZ的意思要把这两个BEAN的功能都在所谓的DAO部份的模块中实现的话，这两个BEAN就不用了。单次开发看来是没什么问题。但比如dbbean，假设现在开发用的是ODBC桥接，而以后改用JDBC的话，这次写的M层模块的CODE就要改还要再编译，虽然这也没什么工作量，但要是其它问题呢？比如写回DB的代码中发现的一个原则性错误，要一个大的修改甚至要得写，那就要从所谓的DAO模块中提取这部份代码重写，若再衰一点，一个没有经验的程序员可能在代码中把写回DB的过于溶入模块无法抽取，那就要重写整个模。
我是这样想的所谓的LZ的M层可以只要一类BEAN。LZ所说的体系结构，数据模型和业务是分开的，其实是可以都封装在这类BEAN中的，但在BEAN中可以的分离的，但在外部看不出来，只看到一个M层的BEAN。在这类BEAN中的业务逻辑部份，再由的dbean vobean的对象构成，这样易于修改维护。
说白了就是为了架构清晰，可读性强。
每一层负责每一层的任务，这样在测试，维护时也很方便。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
我同意这个我的问题是为什么要有类似vo bean这种东西啊-------------------------------------------------------
这是面向对象的充分表现，bean充当了数据库的关系型数据和面向对象的组合型数据互相转换得角色。request承载了太多深层次永不倒的东西，既然无用，就不应该传过去。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
确实多写东西．可是考虑到不用在做结构体和来回过滤数值的原因．．
传request确实简单啊-------------------------------request里面有很多东西，即使是数据也是一组map一样的数组数据，它本身没有多少业务意义。
简单是简单，如果只是一个简单的系统，我想连分层都不需要，直接用jsp，或者servlet写就可以了。
这个世界上之所以存在这么多的架构，并不是凭空想出来的，这是当系统做到一定规模，遇到一定的问题，慢慢总结出来的。
如果你觉得你的做法完全符合你现在做的系统的话，完全没有必要上什么框架。
都不符合楼主的要求吗？
俺也胡乱说说吧
所谓三层即
①视图层：负责前台数据显示
②模型层：表示业务数据和业务逻辑
③控制器：接受用户数据传递给模型层，还负责页面转向之所以这样分层有一方面是为了降低他们之间的耦合性
你们经理说你不符合三层的结构是因为你将request传递给了DAO，虽然这样做是可以的，并且还省了不少劲，但这样做得后果是所有的数据全部纠结在一起，这样他们之间的联结过于紧密，不利于测试，无法复用！
推荐做法是
一个Action对应一个Form， 在Action用到的数据只从Form中取
一个Bizz 对应一个Entity，逻辑中的数据只从Entity中取
一个Dao 对应一个Peer， Dao中的数据只从Peer中取
当然叫法有所不同，让它们这样分离开，只在关联的地方赋一下值
对于你应当将Action中Request取得的值赋给Entity，而不是直接传给后台Dao，Dao只是对数据库进行操作的，不应当包含其它的东西，每个层只是专注于自己处理的过程，各层之间进行数据传递就可以了。
你可以试着复用一下自己的程序，估计能有所收获
说点自己的想法~mvc模式我感觉就是为了把数据和业务分开，（实体entity,业务逻辑bean）利于程序员的后期维护。而对于request 不知道楼主是用什么框架实现的！你可以改变一下方法！在view层，和model层里的数据传输可以不用request 在model层里生成一个form 对应 view 层里的表单名生成set ,get 这里就可以不用request表单里的数据model层里想用什么就用什么了！
而换成了JSF
按照你的意思写出的代码维护起来就麻烦了~~
如果3层明确,则很容易维护~