我为什么不用struts

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

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

简单就是最好的设计，现在讲点道理，顾虑可真多啊。

我要说的就是struts又复杂，又不能满足现在的需求啊。
再说了,order.user.id之类的命名又不是什么http规范，仅仅是struts为了能够把http参数注入action而约定的input命名格式。
采用json格式提交数据，既能够使代码最简化，又能提供最大的灵活性。

我的同事或者下属不一定要和我差不多水平，他们不学我的框架开发，就只能学更复杂的struts1或者struts2了。
我的框架仅需要1-2个小时的学习成本而已，前端都是封装好的Js控件，一般都是需要编写的js代码主要有form.getValue(),grid.getValue()和tree.getValue()等等，然后把得到的结果提交到服务器段就行了。

同意。就跟写代码一样，不用注释的代码就是最好的代码。但是你也认为你和你的同事或下属都是一样或差不多的水平吗？  你认为你永远不会带入学生开发人员吗？  我相信学生也可以很快去学习你写的框架，但是不一定他能理解你所完成的功能。

你说的两个问题，可以归纳为：
1：Struts2 的Action是有状态的，存在成员变量；
2：Struts2 不能很好地支持json/xml甚至jpg等格式的输出；


你这两个问题，可以使用Spring MVC 3 来解决，但是如果使用Spring MVC 3，又引入一个致命的问题：Spring MVC 3 使用annotation可以把藏在任意层次的类映射到一个url上，这样，如果项目管理人员无法强制约束组员的命名风格和包路径存放规范，会造成到看到一个url，到处去找其对应的控制器类的问题。
使用struts2-convention-plugin 就不会有这个问题，因为它是使用约定的，你不按照约定来存放和命名action，你的url根本就无法访问，程序也运行不起来。

另外，Struts2所使用的模型驱动还有一个问题：当你的页面输入框内输入的数据类型，和实体类定义的数据类型不一致时（比如实体类A字段类型为Integer，而页面上为该字段输入了aaa），提交页面，Struts2既不报错，也不能执行，程序根本就不会进入Struts2的方法（使用struts2-convention-plugin 时），这是一个大问题。

但是和Spring MVC 3 的包路径无约束造成的项目混乱相比，Struts2的种种缺点我还是忍受了。

所以综合上述，我还是选择了Struts2