|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-07-23
不知道rtm的spring MVC掌握到什么程序度了。我也觉得Spring存在着一些缺点，但rtm提的那几点显然站不住脚。
rtm 写道 一般一个稍微复杂点的action大概起码要用到3，4个entity，如果不是像webwork这样通过action属性传递参数，估计你光光得到这些需要的entity就要写好多行代码了。而且如果你的action是可以执行多个请求的，那么每个执行方法比如insert(),update()当然也要从新去取这些需要的entity。 Spring MVC与webwork2的最大的区别是它的Action的状态保持，因为Webwork里的Action本身就是Model,所以它可以通过设置Action里的property就能获得参数。 而Spring MVC则是将数据的状态传递到Command对象，所有的这些参数传递都是自动完成，而且Spring的数据绑定用的是它的IOC容器的数据绑定机制（看一下BeanWrapper和相关的类吧), 因此Spring MVC的数据绑定功能是非常强大的,页面上的数组、List全部都可以一次性自动读到Command对象中。而且它提供的binder机制也异常灵活,所有自定义的数据都可绑定到Command对象。 姑且认为Webwork2的数据绑定功能与Spring MVC一样强大，Spring也不会比Webwork2写更多的代码。只是两者存放property的位置不同,Spring存放在Command对象里,Webwork2直接存放在Action里。 rtm 写道 如果你需要向页面传递一个以上的对象，比如我要传几个List（页面中生成下拉选择用），几个entity那估计你传递的代码也要写好多了。 其实是同样的问题。Webwork2里直接将要传递的属性set到Action里，Spring MVC将之设置到ModelAndView的HashMap里。同样的代码量，只是实现的方式不同而已。（如果一定要计较代码量，可能set比HashMap的put少打几个字,呵呵.who cares?) rtm 写道 我觉得配置本身是一个问题，因为配置，那么你必须将代码跟配置保持一致，比如我在代码中改个跳转的页面，代码中改完后必须同步去修改配置，而且在多个人开发的请况下，维护这个配置的版本一致也是一个问题。webwork中可以通过注释来生成，在很大程度上解决了这两个问题。使得不需要去关注配置，只需关注代码。 看来rtm对Spring的IOC容器也不太熟悉。IOC容器的最基本的目的就是要让程序的一些状态（如对象关联，基本属性，是否支持AOP）与行为分离，使我们在开发的程序的时候无需关心这些烦心的事，并使程序的行为在代码里保持透明。利用IOC最基本的特点就可以把页面跳转挪到配置文件里，代码里根据无需关心跳转的问题。当然你也可以只在代码里写跳转，随个人喜好。 呵呵，其实这个观点是对整个Spring的否定，完全否定了IOC容器存在的价值。 rtm 写道 request，session是用来在页面之间传递变量的，不过在我们action的实际使用中需要的是已经组装好的entity对象，所以我们使用各种手段来自动组装entity对象，包括自动从页面取参数组装成entity（甚至是entity元素的一个List）和自动传递entity的属性到页面显示，而不用手动去做（eg:request.setAttribute("lista",list)）。 首先，Spring里是不需要写request.setAttribute("lista",list)）这样的代码的，只要用ModelAndView就可以了。光就写法上来说仍然是Webwork的属性set和Spring的HashMap的put之间的差别. 关于request, response的隐藏,以及set和put的选择,很大程度是个人喜好的问题，呵呵，前面robbin已经说得好多了，我也不想争了。 |
| 返回顶楼 | |
|
发表时间：2005-07-23
最近正在疯狂地写代码，一直没空写后面的内容。下周空点了准备再写一点Spring MVC的内部实现机制和一些简单扩展及部分源码分析。呵呵，要学的东西太多了，忙完之后还得静下心来多学些东西。
|
| 返回顶楼 | |
|
发表时间：2005-08-02
xiecc和robbin老大都说的很精彩
我现在做的项目就准备用spring,正在刻苦学习中... 文章很有启示呵呵 |
| 返回顶楼 | |
|
发表时间：2005-08-03
我不觉得spirng的mvc很烂。
不过说实话，spring的mvc需要搭配很多东西才能很“漂亮”的跑起来。 比如jstl，el语法，display tag。因为spring 自己不搭配。 至于spring tag，这个只是验证用的东西。用不用随意。 不过我真正在一个项目里，用spring也不是什么很难的事 我带过的一个项目。连我一共是3个人。还有两个，一个当时还没有毕业，到公司来作实习的，最大的一个项目是.net的课程设计，另一个mm有三年的工作经验，不过原来是写vb6的，没有写过一行java代码。 可能这两个小朋友悟性都很高，我只是用jstl+display+spring+hibernate写了两个功能作样子，剩下的都是他们作的，我之后只管review就可以了。此外帮他们封装了一个串口的通讯包。 结果一个20个页面的web程序连测试带文档三个人一个月天就搞定了，平均一个工作日实现一个页面。可以说是公司里开发速度最快的一个产品。实习的小朋友开开心心拿着项目成果交毕业设计去了。不过因为是全新的，没有什么遗留问题的困扰，设计上不花什么时间。 所以我觉得所谓功能高低等等什么的纯粹扯淡。如果当初我用webwork作，我想他们一样能够依葫芦画瓢作下来。 这些框架争不出哪个好哪个差。 要说差，就是用的人自己差，还没有真正吃透。 |
| 返回顶楼 | |
|
发表时间：2005-08-05
说spring mvc很烂的最好能给大家讲讲理由，否则有两眼朝天的嫌疑
我觉得要说最好的MVC框架是哪个真的难说，而且长江后浪推前浪，许多非MVC的web框架也很有潜力。但spring mvc怎么也是前几位的mvc框架，不会很烂吧。 个人感觉spring mvc考虑得面面俱到，理论上的确是很好，实际使用上也不觉得有哪里不好。搞清楚了真的也不是多麻烦。恐怕有不少人是看了夏昕的opendoc就直接照搬结论了。而夏昕应该是没怎么实际使用SpringMVC，至少他的那份spring开发指南中对mvc部分只是蜻蜓点水。 
|
| 返回顶楼 | |
|
发表时间：2006-02-14
项目连着用struts+spring，被配置一致性的问题折腾死了(可能没好的IDE)
个人迷恋spring，差不多有了 "只要是spring的,就是好的"想法 但事实是：花了不到一个星期的时间，我总结了平时项目web部分麻烦的地方，然后用spring mvc实现，并没有怎么复杂的感学(可能是问题太简单  )
我得到切实得到好处是： 1，学习周期短，可以很好的利用你原来的jsp/jstl技术 2，一致的文件配置 3，纯天然的ioc支持 4，比struts少写了很多配置代码 5，少而精又相对干净的tag 6，自由的command/form 7，好用的拦截/异常处理 .... 在现在spring已经普及化应用的情况下，像我这样忍着struts大可以直接上手spring mvc 它与webwork之间的优劣争执，个人认为大多是主观问题 我的主观和xiecc一样，支持spring mvc 广告：架子太多太累，就让spring绑你整理吧(-_-) |
| 返回顶楼 | |
|
发表时间：2006-02-15
没真正实用过spring mvc，（其实webwork, struts都没用过），所以不能说springmvc好用与否。
只是前段时间因为需要看了一下spring mvc的代码。所以从架构上，不喜欢spring mvc和spring oc的耦合。按我的观点，ioc, mvc, aop都是正交的单独概念，互相强制耦合从架构上不太美观。（相比之下，spring aop就好得多。）。按我的观点，spring mvc可以缺省用spring ioc来配置，但是不应该死死绑在spring ioc上，应该能在其它的容器内，甚至任何容器之外运行，才是真正的light-weight。 从仅有的粗浅适用经验上来说，spring通过一些特殊的bean name的naming convention来指定mvc的一些组件，也感觉不太舒服，架构设计显得随意，不够精巧紧凑。 |
| 返回顶楼 | |
|
发表时间：2006-02-17
引用 ioc, mvc, aop都是正交的单独概念，互相强制耦合从架构上不太美观。
二者粘得是显得紧了引些，不过业务层这种“大场面”即然都选了spring， 给他配个贴身小护士，也不是太过份的说 |
| 返回顶楼 | |
|
发表时间：2006-04-22
要是用springframework开发就用自身一套的东西，配置上一个其他的MVCframework会感觉很不舒服。springMVC虽然设计复杂，但她有足够的灵活性，分工很细致。用过springMVC开发过的朋友有没有感觉与单独使用其他框架的MVC有什么不同啊？
|
| 返回顶楼 | |
|
发表时间：2006-04-23
xiecc 写道 五、 Spring提供了不错但不够充分的interceptor机制
回头看一下struts，它在架构里甚至没有给我们提供hook point的机会，我们没有任何机会加入自己的interceptor。我们只能通过重载struts的RequestProcessor类来进行一点有限的扩展。 到了Webwork2，似乎interceptor一下子成了整个Framework的核心，除了Action的核心部件，其它所有的东西都是interceptor。它的超强的interceptor功能使们扩展整个架构变得非常方便。有人称这种interceptor为AOP，Jason Carreira则自豪地宣称这个叫做pragamtic AOP。我不认同这是AOP，它只是简单的interceptor机制。但不管如何，它的interceptor确实有强大的功能。 Spring也提供了它的interceptor机制，它的HandlerInterceptor三个interceptor方法：peHandle, postHandle, afterCompletion。分别对应Controller执行前，Controller执行后和page render之后。虽然大多数情况下已经够用，但是从功能上来说显然它没有Webwork2强大。从AOP的角度来看，它没有提供around interceptor，而只有before与after interceptor。这意味着我们无法在interceptor前后保持状态，最简单的情况假如我们要计算一个Controller的执行时间，我们必须在执行完before后把begintime这个状态保持住，再在after里把它调出来，但是显然这个状态保持会是个问题，我们不能把它放到instance变量里，因为interceptor不是线程安全的。也许通过ThreadLocal可以解决这个问题，但是如此简单的功能要用到这样的方法来处理，显然这个Interceptor本身设计上还是有点问题的。 Webwork里有ActionContext，ActionContext是基于ThreadLocal的，所以把状态装到ActionContext里也没差…… 毕竟ActionContext是对每个Action 而言的。正好让Interceptor和Action交互。 Action里觉得必要了，改下状态，外面的Interceptor也就知道了。 |
| 返回顶楼 | |
