|
锁定老帖子 主题：spring3mvc与struts2比较
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-06-23
slaser 写道 downpour 写道 有关Struts2的Action职责问题。我认为可以根据功能模块进行划分。一个功能模块，一般会有2到3个Action，每个Action将承担一定的职责。
比如User相关的功能模块。可能需要2个比较基本的Action：UserController和UserView。UserController负责User相关的操作，UserView负责User显示的相关操作。如果User这个功能模块太大，比如牵涉到User的权限，那么就需要增加新的Action，例如UserRoleController和UserRoleView。 无论怎么说，按照Controller和View进行Action的功能分类，是目前为止我认为比较合理的一种方式。View的操作对象往往是id和entity本身，所以这2个变量会在一个Action中共享，你根本不用去担心某个parameter是for哪个操作的。你的关注点只要停留在你的操作本身就可以了。 感觉这样划分并不易把握。我觉得一个页面一个action是最好操作的，虽然可能会形成一些冗余，但是可维护性很好。 你的感觉应该不准确。 举例来说，save和update的Action在多数情况下是分页面但是同Action的。 |
| 返回顶楼 | |
|
发表时间：2010-06-24
downpour 写道 slaser 写道 downpour 写道 有关Struts2的Action职责问题。我认为可以根据功能模块进行划分。一个功能模块，一般会有2到3个Action，每个Action将承担一定的职责。
比如User相关的功能模块。可能需要2个比较基本的Action：UserController和UserView。UserController负责User相关的操作，UserView负责User显示的相关操作。如果User这个功能模块太大，比如牵涉到User的权限，那么就需要增加新的Action，例如UserRoleController和UserRoleView。 无论怎么说，按照Controller和View进行Action的功能分类，是目前为止我认为比较合理的一种方式。View的操作对象往往是id和entity本身，所以这2个变量会在一个Action中共享，你根本不用去担心某个parameter是for哪个操作的。你的关注点只要停留在你的操作本身就可以了。 感觉这样划分并不易把握。我觉得一个页面一个action是最好操作的，虽然可能会形成一些冗余，但是可维护性很好。 你的感觉应该不准确。 举例来说，save和update的Action在多数情况下是分页面但是同Action的。 你这个例子确实使用相同action比较好，但是也不是绝对的，如果update和create有比较多不同的逻辑，是可以分2个action的。反过来如果完全差不多，为何不用一个页面？ |
| 返回顶楼 | |
|
发表时间：2010-06-24
curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。 所有从开发效率和维护效率上考虑。 我支持curd操作 集中在一个 action。 把curd分成4个action绝对会导致开发人员的反抗。 |
| 返回顶楼 | |
|
发表时间：2010-06-24
最后修改：2010-06-24
byk 写道 curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。 所有从开发效率和维护效率上考虑。 我支持curd操作 集中在一个 action。 把curd分成4个action绝对会导致开发人员的反抗。 你要多考虑一下交接的成本，由于各种原因导致这个action让别人来维护，挤在一起很容易让接手的人头晕。 维护和修改成本一般远大于开发成本。 即使是同一个人维护，半年不碰再让他改，没有完整注释的话，一样有可能忘记的差不多了，此时当然是合理（有些时候的save和update逻辑没那么简单的）的拆分Action更好一点。 |
| 返回顶楼 | |
|
发表时间：2010-06-24
icewubin 写道 byk 写道 curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。 所有从开发效率和维护效率上考虑。 我支持curd操作 集中在一个 action。 把curd分成4个action绝对会导致开发人员的反抗。 你要多考虑一下交接的成本，由于各种原因导致这个action让别人来维护，挤在一起很容易让接手的人头晕。 维护和修改成本一般远大于开发成本。 即使是同一个人维护，半年不碰再让他改，没有完整注释的话，一样有可能忘记的差不多了，此时当然是合理（有些时候的save和update逻辑没那么简单的）的拆分Action更好一点。 靠谱 所以说赶紧扔了struts2吧 springmvc3从根子上帮助了开发人员 |
| 返回顶楼 | |
|
发表时间：2010-06-24
最后修改：2010-06-24
xly_971223 写道 icewubin 写道 byk 写道 curd操作通常都是一个开发人员负责，
需求变化或者其他原因需要修改维护的时候通常都需要curd同时修改。 所有从开发效率和维护效率上考虑。 我支持curd操作 集中在一个 action。 把curd分成4个action绝对会导致开发人员的反抗。 你要多考虑一下交接的成本，由于各种原因导致这个action让别人来维护，挤在一起很容易让接手的人头晕。 维护和修改成本一般远大于开发成本。 即使是同一个人维护，半年不碰再让他改，没有完整注释的话，一样有可能忘记的差不多了，此时当然是合理（有些时候的save和update逻辑没那么简单的）的拆分Action更好一点。 靠谱 所以说赶紧扔了struts2吧 springmvc3从根子上帮助了开发人员 没发现“根子上”啊，个人认为两个框架都可以用，struts2还更普及一点，了解的人更多一点，加一点规范即可，并不存在哪一个框架有压倒性的优势。 在页面逻辑复杂，表单参数繁多的时候，默认就是多例的Struts2也是很好用的。 题外话：页面逻辑复杂可以通过交互方式调整（适当的地方用ajax），能简化Action这一层的代码，当然前端会增加一些JS代码。 |
| 返回顶楼 | |
|
发表时间：2010-06-24
最后修改：2010-06-24
在web层只关心的就是上传文件功能... 现在做网站或系统全部静态化..... 开发效率120% 网站大了，什么代码都有。。整个网站的代码都乱七八糟的。 |
| 返回顶楼 | |
|
发表时间：2010-06-24
superyang 写道 在web层只关心的就是上传文件功能... 现在做网站或系统全部静态化..... 开发效率120% 网站大了，什么代码都有。。整个网站的代码都乱七八糟的。 网站大了就要做项目切分了 大项目切成多个项目 不会这么乱 |
| 返回顶楼 | |
|
发表时间：2010-06-24
最后修改：2010-06-24
xly_971223 写道 superyang 写道 在web层只关心的就是上传文件功能... 现在做网站或系统全部静态化..... 开发效率120% 网站大了，什么代码都有。。整个网站的代码都乱七八糟的。 网站大了就要做项目切分了 大项目切成多个项目 不会这么乱 有此人不会写代码的,不管代码的质量怎样,只要实现功能就OK,最后网站变得慢,那时想提高网站性能也就很难了... ps:这几天,网站变慢了,什么方案都弄,我是怕了... |
| 返回顶楼 | |
|
发表时间：2010-06-24
superyang 写道 xly_971223 写道 superyang 写道 在web层只关心的就是上传文件功能... 现在做网站或系统全部静态化..... 开发效率120% 网站大了，什么代码都有。。整个网站的代码都乱七八糟的。 网站大了就要做项目切分了 大项目切成多个项目 不会这么乱 有此人不会写代码的,不管代码的质量怎样,只要实现功能就OK,最后网站变得慢,那时想提高网站性能也就很难了... ps:这几天,网站变慢了,什么方案都弄,我是怕了... 这是你们招聘的时候，人员能力参差不齐的原因。 关键位置在人力上花钱是不会浪费的。 |
| 返回顶楼 | |
