我为什么不用struts

xiaodong还趟je的浑水啊？这里回帖的大部分人全职做过的项目还没有你兼职玩过的，就一帮只会扯蛋的

。。。。
复杂的对象组合，是在service层完成。action本身就不应该做这些东西。你在action做这些封装本身就是你设计的失误！action只是简单的中转。也就是说你这个order直接放在action的属性中，或者可以定义model驱动。界面直接order.xx.xx就完事了。多麻烦的事？
还json,还map，不知道你要搞什么？你搞的那点东西就你自已懂，别人怎么办？以后的人怎么办？struts是大家都懂的，后来的人学习成本低。也利于产品的维护。不懂就学,别jjyy。
我以前公司有个人拿他写的所谓的mvc框架给我看，说多么多么好，被我一陈批。不知道这个人是不是你。

 

<input type="text" name="order.details.product.id"/>这样是你说的订单中的订单明细中商品的关联，输入的值是最终被关联的商品的id。

 

不知道我这样说你是否明白。

 

order.details是一个集合，而不是一个简单属性。你能用order.details.goods.id的方式让order对象关联到一个集合，而集合中又包含一些goods对象么？
复杂对象的组装如果都在service层完成，那么在用户在做一件事情的时候，你不得不让用户的浏览器和服务器进行很多次的交互。当然你可能没有见过复杂的交互，这不奇怪的。但是最好别乱咬人。

你没用过前端可编辑表格控件吧。用惯了桌面客户端的企业用户，不会允许你在浏览器放一大堆Input来当做表格的单元格来用的

麻烦几位，技术出身就只牵扯技术就算了。  没什么好咬人不咬人的

在我眼里，struts还有几个关键的缺点，所以我用了3-5个项目后就不用了。

主要的缺点有这么些：

1、输入输出变量范围定义不清晰。在一个action中，所有输入输出变量都是作为对象变量存在的，既无法区分某个变量是属于哪个方法的，也不能区分哪个变量是输入变量还是输出变量。有人说，我每个请求都用单独的action来处理不就行了。这个办法的确可以区分每个请求之间的输入输出，但是你会面临action数量急剧膨胀的问题。

     输入输出变量定义不清晰的带来的问题是代码可读性比较差。使用struts的时候，极端情况下，你得把jsp+action+js结合起来看才能确定某个请求有哪些输入输出。这对项目的维护者来说实在是件很痛苦的事情。


2、struts在处理ajax请求的时候太不方便了，虽然你可以配置一个插件让strus具备返回json result的功能。但是目前的插件距离我的实际需要还是有差距的。主要的问题在于，struts现有的json插件不能定义java对象序列化到json对象时的映射策略。就拿User对象来说吧，假如我目前设计的是订单界面，订单又引用了User对象作为订单的制单人属性。那么在序列化Order对象到前端的时候，我只需要序列化User对象的id,name就够了，user对象的其他属性可以统统不要。但我如果在维护用户的模块中，显示用户列表的时候，通常要显示用户对象的大部分属性。因此java对象到json对象的序列化策略应该是运行时动态设定的，不可能用annotation来申明。但struts以及struts插件并没有提供运行时根据请求为某个类选择不同映射策略的功能。


struts2，学习成本不可谓不高，功能不可谓不强大，但不符合我的需求。


学习strus2，假如不花个把月时间静下心来学习和实践，估计没人敢说自己精通strus2了。但mvc真的有必要那么复杂么？


mvc是什么？他应该能干什么？他的核心价值在哪？最小的mvc应该包含哪些功能？我们自己写一个mvc如何？自己写一个mvc框架需要超过一个月时间么？