|
锁定老帖子 主题：spring3mvc与struts2比较
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-02-17
george 写道 downpour 写道 shiren1118 写道 你觉得这有啥可炫耀的吗？spring的多view解析实现这个跟玩一样
看看这兄弟的帖子吧http://www.iteye.com/topic/748006 帅哥，咱不再做框架之争了好么？SpringMVC与Struts2都是优秀的Web层框架。框架的优劣，是程序员自身的哲学选择。有些东西，我说是缺点，你却说是优点，这是永远也争不清楚的。 在这里我需要给那些使用SpringMVC的同学提个醒。Annotation进行UrlMapping在大型的web应用中的可维护性是值得质疑的。在团队开发中，这一问题显得格外严重。所以，请不要神化SpringMVC的某些功能。谢谢。 顶，支持。 这点我深有体会，Spring MVC 3.0.5 留给开发者的自由度太大了，让开发者可以在一个controller 里，在class上和method上自由定义url，这样的话，会造成同一个包路径下的controller 映射到任何层次级别的url上去，也会造成不同的包路径下的controller 映射到相同层次的url上去，甚至会出现多个controller 映射到同一个url，一句话概括就是：【杂乱无章】，这样的自由度泛滥，在大的项目中必定造成维护上的混乱，不要指望每个程序员都是命名规范，自觉遵循项目约定的“顺草”，基本上每个项目组都是“杂草丛生”。 这一点其实我在最早的讨论中就指出来了。SpringMVC的Annotation来指定URL Mapping的可维护性为0。 这里的本质问题在于Annotation和XML到底谁更加适合来做某种类型的配置。 当我们引入一个Annotation，实际上获得的好处在于我们可以在Java Code级别解决配置问题，但同时，我们也引入了其他的问题： 1） 引入了Annotation，就引入了对框架的强依赖，一个原本可以单独测试的东西，却必须放在容器中做集成测试。 2） 引入了Annotation，就将这个Annotation所代表的配置类型，分散到了不同的Java Code中。就像在一个沙地里面，我们要寻找散落在各处的黄豆，实际上是非常困难的。 当我们引入XML的时候，虽然我们引入的是一个额外的配置文件和额外的配置，但是我们却获得的统一的查找路径，可维护性得到了保证。 |
| 返回顶楼 | |
|
发表时间：2011-02-17
最后修改：2011-02-17
downpour 写道 george 写道 downpour 写道 shiren1118 写道 你觉得这有啥可炫耀的吗？spring的多view解析实现这个跟玩一样
看看这兄弟的帖子吧http://www.iteye.com/topic/748006 帅哥，咱不再做框架之争了好么？SpringMVC与Struts2都是优秀的Web层框架。框架的优劣，是程序员自身的哲学选择。有些东西，我说是缺点，你却说是优点，这是永远也争不清楚的。 在这里我需要给那些使用SpringMVC的同学提个醒。Annotation进行UrlMapping在大型的web应用中的可维护性是值得质疑的。在团队开发中，这一问题显得格外严重。所以，请不要神化SpringMVC的某些功能。谢谢。 顶，支持。 这点我深有体会，Spring MVC 3.0.5 留给开发者的自由度太大了，让开发者可以在一个controller 里，在class上和method上自由定义url，这样的话，会造成同一个包路径下的controller 映射到任何层次级别的url上去，也会造成不同的包路径下的controller 映射到相同层次的url上去，甚至会出现多个controller 映射到同一个url，一句话概括就是：【杂乱无章】，这样的自由度泛滥，在大的项目中必定造成维护上的混乱，不要指望每个程序员都是命名规范，自觉遵循项目约定的“顺草”，基本上每个项目组都是“杂草丛生”。 这一点其实我在最早的讨论中就指出来了。SpringMVC的Annotation来指定URL Mapping的可维护性为0。 这里的本质问题在于Annotation和XML到底谁更加适合来做某种类型的配置。 当我们引入一个Annotation，实际上获得的好处在于我们可以在Java Code级别解决配置问题，但同时，我们也引入了其他的问题： 1） 引入了Annotation，就引入了对框架的强依赖，一个原本可以单独测试的东西，却必须放在容器中做集成测试。 2） 引入了Annotation，就将这个Annotation所代表的配置类型，分散到了不同的Java Code中。就像在一个沙地里面，我们要寻找散落在各处的黄豆，实际上是非常困难的。 当我们引入XML的时候，虽然我们引入的是一个额外的配置文件和额外的配置，但是我们却获得的统一的查找路径，可维护性得到了保证。 XML也不推荐大量使用，最好是使用约定，不按照约定来命名类和方法，根本就无法访问url,这样即减少了配置文件，又能很方便地找到URL所对应的控制器类，而且还能强迫那些“胡乱写类名、方法名”的“懒汉”把命名规范起来。 |
| 返回顶楼 | |
|
发表时间：2011-03-18
struts同样可以做方法上的拦截,这样配置就可以了
<action name="login" class="xx.LoginAction" method="login"> <interceptor....../><!-- interceptor A --> <result...../> </action> <action name="logout" class="xx.LoginAction" method="logout"> <interceptor....../> ><!-- interceptor B --> <result...../> </action> |
| 返回顶楼 | |
|
发表时间：2011-03-26
chrislee1982 写道 struts同样可以做方法上的拦截,这样配置就可以了
<action name="login" class="xx.LoginAction" method="login"> <interceptor....../><!-- interceptor A --> <result...../> </action> <action name="logout" class="xx.LoginAction" method="logout"> <interceptor....../> ><!-- interceptor B --> <result...../> </action> 我赞成okayeye的意见，在富客户端的情况下，springMVC和struts2的流转控制可以放到客户端来做，比如Flex，服务器端尽量只做数据读写和服务集成，这样可以获取更高的并发流量 |
| 返回顶楼 | |
