已采纳回答 / 我觉得有点菜
安装java ee插件 Help-->Eclipse Marketplace-->搜索eclipse for java ee(大致这名就能搜到...)-->install-->选Web项
2016-10-03
老实说，老师对MVC的理解不够深。MVC的模式的分层设计的确是为了视图层和模型层的解耦而生。控制层起到一个隔离的作用，这样的设计是具有正交性的。如果有N个视图和M个模型的话，只要写N*M个控制器就可以生成N*M种模式（还没包括模型层的M * （M－1）的组合），这样重复的代码是可以控制到最低的，也是最易于控制的。
2016-10-02
我来解释（逗逼）一下，错误信息的处理流程，仅供参考
1.Action类的父类ActionSupport中有一个收集错误信息的容器Map，错误信息是名称fieldName和描述信息errorMessage的键值对
2.struts框架把login.jsp中的表单数据传递给Action类的方法进行处理后，如果有错误则错误信息被添加到容器里，方法返回值INPUT
3.struts框架从处理结果中提取出错误信息，并注入到INPUT对应的jsp文件中，将该jsp返回给用户
4.用户得到jsp后，根据标签<s:fielderror>的属性name匹配错误信息fieldName，将错误信息显示在视图对应位置
1.Action类的父类ActionSupport中有一个收集错误信息的容器Map，错误信息是名称fieldName和描述信息errorMessage的键值对
2.struts框架把login.jsp中的表单数据传递给Action类的方法进行处理后，如果有错误则错误信息被添加到容器里，方法返回值INPUT
3.struts框架从处理结果中提取出错误信息，并注入到INPUT对应的jsp文件中，将该jsp返回给用户
4.用户得到jsp后，根据标签<s:fielderror>的属性name匹配错误信息fieldName，将错误信息显示在视图对应位置
2016-09-29
我来解释（逗逼）一下，方法3中struts框架的数据处理流程
1.和方法2不同点：把User换成List其它流程一样
2.关键在于理解逻辑视图分离的思想，框架先提取视图中的表单数据，用action的属性name在xml中找到匹配的Action类，并实例化这个类的一个对象，用set方法把表单数据注入这个对象，执行xml中method指定的方法，用返回值匹配result返回对应视图
3.以上流程可以看出，视图不需要考虑怎么把数据传给逻辑，逻辑也不考虑怎么得到数据怎么把结果视图返回给用户，一切由MVC框架完成，逻辑视图控制器相互独立，这就是解耦，可以参考spring中“依赖注入”的概念，本质是一样的
1.和方法2不同点：把User换成List其它流程一样
2.关键在于理解逻辑视图分离的思想，框架先提取视图中的表单数据，用action的属性name在xml中找到匹配的Action类，并实例化这个类的一个对象，用set方法把表单数据注入这个对象，执行xml中method指定的方法，用返回值匹配result返回对应视图
3.以上流程可以看出，视图不需要考虑怎么把数据传给逻辑，逻辑也不考虑怎么得到数据怎么把结果视图返回给用户，一切由MVC框架完成，逻辑视图控制器相互独立，这就是解耦，可以参考spring中“依赖注入”的概念，本质是一样的
2016-09-28
我来解释（逗逼）一下，方法2中struts框架的数据处理流程
1.和方法1不同点：表单数据被注入了User对象，再把user注入LoginAction
2.从Login.jsp视图中得到表单数据后，用action="name1.action"的name1匹配xml中的<action>的name
3.匹配成功的是LoginAction，框架会实例化它的一个对象，由于这个对象有一个User属性，再实例化一个User对象，然后用set方法把表单数据注入user再用set方法把user注入LoginAction
4.执行login方法得到返回值，用返回值找到<result>中对应的jsp视图返回给用户
1.和方法1不同点：表单数据被注入了User对象，再把user注入LoginAction
2.从Login.jsp视图中得到表单数据后，用action="name1.action"的name1匹配xml中的<action>的name
3.匹配成功的是LoginAction，框架会实例化它的一个对象，由于这个对象有一个User属性，再实例化一个User对象，然后用set方法把表单数据注入user再用set方法把user注入LoginAction
4.执行login方法得到返回值，用返回值找到<result>中对应的jsp视图返回给用户
2016-09-28
我来解释（逗逼）一下，方法1中struts框架的数据处理流程
1.用户在login.jsp提交表单数据后，提取<form>的属性action="name1.action"
2.用name1去匹配struts.xml中<action>的属性name，案例中是LoginAction
3.执行匹配成功的action对应的class对应的method，得到返回值
4.用返回值去匹配<result>的属性name返回对应jsp，name被省略了返回默认success.jsp
关键是步骤3中，Struts框架会先实例化class的一个对象，然后用set方法把表单数据注入到这个对象，所以必须先实现set方法
1.用户在login.jsp提交表单数据后，提取<form>的属性action="name1.action"
2.用name1去匹配struts.xml中<action>的属性name，案例中是LoginAction
3.执行匹配成功的action对应的class对应的method，得到返回值
4.用返回值去匹配<result>的属性name返回对应jsp，name被省略了返回默认success.jsp
关键是步骤3中，Struts框架会先实例化class的一个对象，然后用set方法把表单数据注入到这个对象，所以必须先实现set方法
2016-09-28
我来解释（逗逼）一下，案例代码的命名太具迷惑性了，不易理解struts执行流程
1.收到页面请求/HelloWorld/name1_name2_… .action后，用name1_name2_…匹配<action>的属性name="*_*_…"，并用name1代替所有{1}，name2代替所有{2}…以此类推
2.执行对应<action>的对应class的对应method，得到返回值value
3.用返回值匹配<result>的属性name，若精确匹配则返回对应视图jsp给用户；若匹配失败，如果返回值是SUCCESS则返回默认jsp，如果是NONE则返回空jsp，如果是ERROR则显示错误页面
1.收到页面请求/HelloWorld/name1_name2_… .action后，用name1_name2_…匹配<action>的属性name="*_*_…"，并用name1代替所有{1}，name2代替所有{2}…以此类推
2.执行对应<action>的对应class的对应method，得到返回值value
3.用返回值匹配<result>的属性name，若精确匹配则返回对应视图jsp给用户；若匹配失败，如果返回值是SUCCESS则返回默认jsp，如果是NONE则返回空jsp，如果是ERROR则显示错误页面
2016-09-28
