基于《关于Java开发不明白的一些有关问题》，探讨一上Struts1和Struts2
基于《关于Java开发不明白的一些问题》，探讨一下Struts1和Struts2
在《关于Java开发不明白的一些问题》中提及Struts1和Struts2，
只不过是用来作为讨论解耦的一个例子而已,我没有从整体上评价孰优孰劣
事实上,我也是先接触了Struts2后来才看的Struts1，
看到一些把Struts2拿来膜拜，我觉得自己是不是应该好好反思一下?
凡是做过JavaWeb开发的莫不了解MVC,凡是了解MVC的莫不了解Struts
纵观java世界里的Web框架,无论形式上如何变化,其本质上却是大抵相同的
所有,不要见人就问你懂不懂某某框架啊
懂框架不如懂原理,举一反三的道理人人都懂,却不是人人都能做的到
那么,那么多的框架,本质是什么呢?相同点又在哪里呢?
其实,无论外表搞得多炫,核心还是Servlet驱动的
而驱动的模型无外乎两种:请求响应驱动和事件响应驱动
我知道的,基于事件驱动的框架有Seam,
而基于请求响应驱动的就很多了,如Struts1和2,XWebWork,Spring-MVC等等
脱离了这些框架之后,所有的东西都能有Servlet实现
而Servlet+JSP+JavaBean就是一个无任何框架的开发模式
这里看好了,JavaBean框架无关的,而JSP现在有多有视图模型可以替代
那么,框架的主要功能是什么呢?,就是取代Servlet的逻辑控制作用
在Struts中,取代Servlet的对象就是Action,
下面,我们来看看Struts1和2中Action的角色有什么不同
在MVC框架中,M作为数据承载的对象,是有状态的,
具体讲,就是一个对象有属性,通过方法的调用来改变属性的值,从而达到状态变化
如果M纯粹作为数据载体的话,那么它的状态变化需要外界来驱动
就像一辆车子,车子本身是不能动的,需要由人来驾驶
在String1中,M就是ActionForm,而C就是Action,
通过Action调用方法并将ActionForm作为参数,来改变ActionForm的属性,
从而完成对客户端的响应
这里,Struts1的一个弊端就是这个JavaBean不是框架无关的,而是需要继承框架的一个基类
为了解决这个弊端,到了Struts2,Struts已经完全否定了自己,转投XWebWork的怀抱
我想说的是,这个自我否定,做得有点过火了,因为你从本质上将还是一个Web框架,
我们将耦合与内聚,你把粒度放大,其实耦合不过就是更大粒度的内聚
不是解耦不是为了方便,耦合的越紧效率越高,使用越方便,这就是集成,它的缺点就是不适应变化
那么我就说了,Struts2你再怎么变化就有一点是不需要变化的,
那就是——你究竟不过是个Web框架
我们来看看Struts2的Action，
第一，action本身包含业务逻辑的数据，那么它承担着M的角色
第二，action还能执行方法，改变自身的属性，那么它同时承担这C的角色
所以在Struts2中，action是自驱动的，不需要外界的干涉，便能改变自己的状态
这就像一辆无人驾驶的汽车一样，有些人觉得这很爽，有些人觉得很不爽？为什么呢？
——因为有些人喜欢开车，有些人不喜欢开车！
也就是有些人喜欢自己控制代码的流程，而有些人却想什么都交给框架做
基于以上的比较，我们来看看Struts1和Struts2有关解耦的问题
可以这么说，即使什么框架都不用，纯粹的Servlet+Jsp+Bean都能解耦，
所以没有什么框架不能解构的，如果你觉得不能解耦，那么就是你的代码设计本身有问题？
还是举个例子吧：
有人说，Struts1中action方法里带有Request和Response对象，无法解耦
我想说，至少有两种办法来解耦：
第一，自己创建Request和Response对象对象
这两个对象不过就是个接口声明,你完全可以有的实现,如果使用了适配器模式,那就更方便了
第二,在需要从Request对象获取数据的地方,将变量提升为参数或者属性同样可以解耦
还是一点想说的是,解耦不过是个概念性的东西,主要是为了应对变化,
但是,现在好多人把解耦简单地理解为,我不继承你的类或接口,就是解耦,
这真是匪夷所思!!!!
再举个例子吧,看看所谓的Struts2的解耦~
对于一个数据对象,它就是一个Bean,
这个Bean是框架无关的,它只包含了业务数据,我们可以将它用到各个框架中,
但是在Struts2中,它是一个action,同样包含了业务数据,但是同时包含了业务逻辑
因为它没有继承Struts2的任何接口和类,你认为它是解耦的,
但是当你把它用到其他框架中,有用的只是它的数据,而不是它的处理方法,因为它的处理方法只有Struts2的框架有用
这种解耦的代价就是代码污染,因为一个数据对象到处包含着不能共享的业务逻辑处理方法
把这种情况放在Struts1中,你可能会说它需要继承一个ActionForm类,
不错,的确如此,但是仅仅这一个类,就可以让你免除那么无谓的代码污染
因为这个类属于Struts,你就认为耦合了,如果在JDK中,你就不那么觉得了?
JDK中的类和我们自己编写的类有区别么?除了身份不同罢了~~~~~~~~~
到了这里,也许你会说,我可以对业务数据进行包装,进行从Action到JavaBean的转换,
那么你可以这样,同样Struts1中也可以进行ActionForm到JavaBean的转换,
所以本质上的解耦根本不是由Struts2来提供的,而是在于你的代码设计
发这个帖子的目的,就是想澄清一下Struts2所谓的解耦,不过玩的概念而已
当然你以可以喜欢它,毕竟比Struts1开发更方便
也可不喜欢它,因为它让你更远离技术
在人家玩概念的时候,也许我们更需要明白的是概念表面下所隐藏的实质,
也许这实质不是我说的这样,但是学习不就是一个不断思考的过程么?
PS:
框架自然有它的好处，不然不会有那么多人用它，但是它无形中造成了程序员价值的贬值
个人的愚论：越是底层的知识，有效期就越长;越是上层的东西,依赖性越强~~~~~~~~~~
从更宏观的角度来讲，整天跟着框架跑，奔波于了解和掌握框架的最新特性，
倒不如研究一下框架本身隐藏的技术手段，能够做到以不变应万变
一旦哪天框架的开发者宣布不再维护了，那么,
是否你的学习就到了尽头了呢？还是继续寻找新的替代者？
至于Controller应该是Struts1中的ActionServlet,Struts2中的FilterDispatcher
这句你说的挺对的,但是这些本来就是Servlet的东西,框架不使用它就无法实现,
action 的出现难道不是为了替代Servlet么?
框架替代servlet有什么不好吗？框架能省去你很多要做，要考虑的东西，让你专注于业务需求方面的东西。也许框架封装了很多技术性的东西，你可能会想这造成开发人员的贬值，但事实不是这样的。公司里面更值钱的是那些业务需求人员，是那些管理，架构和设计人员，而不是开发人员。
从高层的角度来说：有一套统一的东西（不管是开源还是自已实现的内部框架），可以形成规范，利于大家快速开发，也利于统一管理。底层的爱跑路就跑路，我不管，我再招，反正懂框架的人好招。
从个人的角度来说：反正是重复劳动，能省我力气最好，本来就是混口饭吃，省一事，赶紧回家看电视玩游戏多好。至于上进的同学，可以抽出更多的时间做自已感兴趣的事。ps:玩游戏也是上进的，哈哈。
那些用项目大小和代码量来衡量人的,真的很无语,我最鄙视~~~~~~~
哪一个框架的代码量不比项目的代码量小?但是哪个才是精华?你懂的~
有的人编了一辈子代码,只不过会用几个框架而已
有的人一行代码不写,照样能成为专家
写和读和思考和创造都是有区别的~~~~~~~~
说实话，你所说的这些我从你身上都没看出来，问个很简单问题
Q: 有两个方案1.servlet + javabean 方案2.Struts2或者其他类似框架
如果你的业务逻辑从十几个数量级上升到上百个甚至上千个数量级的时候你应该选择哪个方案，为什么？
那些用项目大小和代码量来衡量人的,真的很无语,我最鄙视~~~~~~~
哪一个框架的代码量不比项目的代码量小?但是哪个才是精华?你懂的~
有的人编了一辈子代码,只不过会用几个框架而已
有的人一行代码不写,照样能成为专家
写和读和思考和创造都是有区别的~~~~~~~~
说实话，你所说的这些我从你身上都没看出来，问个很简单问题
Q: 有两个方案1.servlet + javabean 方案2.Struts2或者其他类似框架
如果你的业务逻辑从十几个数量级上升到上百个甚至上千个数量级的时候你应该选择哪个方案，为什么？
一般情况下,都是自己开发框架,纵观那些框架,本质上有什么区别?
业务逻辑再怎么上升,那些框架还不是只用一个Servlet搞定?你能给我举个例子,哪个不是?
动不动就呈XX数量级上升,业务逻辑的数据量级在你进行需求分析的时候就确定了
框架替代servlet有什么不好吗？框架能省去你很多要做，要考虑的东西，让你专注于业务需求方面的东西。也许框架封装了很多技术性的东西，你可能会想这造成开发人员的贬值，但事实不是这样的。公司里面更值钱的是那些业务需求人员，是那些管理，架构和设计人员，而不是开发人员。
从高层的角度来说：有一套统一的东西（不管是开源还是自已实现的内部框架），可以形成规范，利于大家快速开发，也利于统一管理。底层的爱跑路就跑路，我不管，我再招，反正懂框架的人好招。
从个人的角度来说：反正是重复劳动，能省我力气最好，本来就是混口饭吃，省一事，赶紧回家看电视玩游戏多好。至于上进的同学，可以抽出更多的时间做自已感兴趣的事。ps:玩游戏也是上进的，哈哈。
呵呵,我从来没有做替代Servlet不好,我只是不想让有些人混淆概念,欺世盗名
我不是说Struts2的Action不好,它的每个请求对应每个Action实例,并不是像它宣传的那样,怎么怎么比单例模式好,
而是它不得不那样实现!
有人讲过Struts2不能用单例模式的原因么?不是它不想用,而是用不了~~
说就好好说，要么就别说，受不了这种人。你到位，你倒是引经据典啊。大尾巴狼，玩深沉。
框架替代servlet有什么不好吗？框架能省去你很多要做，要考虑的东西，让你专注于业务需求方面的东西。也许框架封装了很多技术性的东西，你可能会想这造成开发人员的贬值，但事实不是这样的。公司里面更值钱的是那些业务需求人员，是那些管理，架构和设计人员，而不是开发人员。
从高层的角度来说：有一套统一的东西（不管是开源还是自已实现的内部框架），可以形成规范，利于大家快速开发，也利于统一管理。底层的爱跑路就跑路，我不管，我再招，反正懂框架的人好招。
从个人的角度来说：反正是重复劳动，能省我力气最好，本来就是混口饭吃，省一事，赶紧回家看电视玩游戏多好。至于上进的同学，可以抽出更多的时间做自已感兴趣的事。ps:玩游戏也是上进的，哈哈。
呵呵,我从来没有做替代Servlet不好,我只是不想让有些人混淆概念,欺世盗名
我不是说Struts2的Action不好,它的每个请求对应每个Action实例,并不是像它宣传的那样,怎么怎么比单例模式好,
而是它不得不那样实现!
有人讲过Struts2不能用单例模式的原因么?不是它不想用,而是用不了~~
什么叫它不得不那样实现，什么用不了。用不用单例，在于用它的人想怎么样。
servlet以及struts1，在多线程环境下，对于成员变量的使用是不安全的。这也应该是struts2默认不是singleton，而是prototype的原因。一般struts2的实例都是spring容器管理，scope可以配成singleton或者prototype两种方式。不想多说了，我觉得你对框架了解得还不够深。
那些用项目大小和代码量来衡量人的,真的很无语,我最鄙视~~~~~~~
哪一个框架的代码量不比项目的代码量小?但是哪个才是精华?你懂的~
有的人编了一辈子代码,只不过会用几个框架而已
有的人一行代码不写,照样能成为专家
写和读和思考和创造都是有区别的~~~~~~~~
说实话，你所说的这些我从你身上都没看出来，问个很简单问题
Q: 有两个方案1.servlet + javabean 方案2.Struts2或者其他类似框架
如果你的业务逻辑从十几个数量级上升到上百个甚至上千个数量级的时候你应该选择哪个方案，为什么？
一般情况下,都是自己开发框架,纵观那些框架,本质上有什么区别?
业务逻辑再怎么上升,那些框架还不是只用一个Servlet搞定?你能给我举个例子,哪个不是?
动不动就呈XX数量级上升,业务逻辑的数据量级在你进行需求分析的时候就确定了
面对你的观点真的很无语，我就再问的直接一点，楼主写过unit test吗？会写unit test吗？
那些用项目大小和代码量来衡量人的,真的很无语,我最鄙视~~~~~~~
哪一个框架的代码量不比项目的代码量小?但是哪个才是精华?你懂的~
有的人编了一辈子代码,只不过会用几个框架而已
有的人一行代码不写,照样能成为专家
写和读和思考和创造都是有区别的~~~~~~~~
说实话，你所说的这些我从你身上都没看出来，问个很简单问题
Q: 有两个方案1.servlet + javabean 方案2.Struts2或者其他类似框架
如果你的业务逻辑从十几个数量级上升到上百个甚至上千个数量级的时候你应该选择哪个方案，为什么？
一般情况下,都是自己开发框架,纵观那些框架,本质上有什么区别?
业务逻辑再怎么上升,那些框架还不是只用一个Servlet搞定?你能给我举个例子,哪个不是?
动不动就呈XX数量级上升,业务逻辑的数据量级在你进行需求分析的时候就确定了
面对你的观点真的很无语，我就再问的直接一点，楼主写过unit test吗？会写unit test吗？
看你这话说的,我从接触java的第一天就写unit test了
而且,java根本就没有学习过,看看jdk api直接就用了
框架替代servlet有什么不好吗？框架能省去你很多要做，要考虑的东西，让你专注于业务需求方面的东西。也许框架封装了很多技术性的东西，你可能会想这造成开发人员的贬值，但事实不是这样的。公司里面更值钱的是那些业务需求人员，是那些管理，架构和设计人员，而不是开发人员。
从高层的角度来说：有一套统一的东西（不管是开源还是自已实现的内部框架），可以形成规范，利于大家快速开发，也利于统一管理。底层的爱跑路就跑路，我不管，我再招，反正懂框架的人好招。
从个人的角度来说：反正是重复劳动，能省我力气最好，本来就是混口饭吃，省一事，赶紧回家看电视玩游戏多好。至于上进的同学，可以抽出更多的时间做自已感兴趣的事。ps:玩游戏也是上进的，哈哈。
呵呵,我从来没有做替代Servlet不好,我只是不想让有些人混淆概念,欺世盗名
我不是说Struts2的Action不好,它的每个请求对应每个Action实例,并不是像它宣传的那样,怎么怎么比单例模式好,
而是它不得不那样实现!
有人讲过Struts2不能用单例模式的原因么?不是它不想用,而是用不了~~
什么叫它不得不那样实现，什么用不了。用不用单例，在于用它的人想怎么样。
servlet以及struts1，在多线程环境下，对于成员变量的使用是不安全的。这也应该是struts2默认不是singleton，而是prototype的原因。一般struts2的实例都是spring容器管理，scope可以配成singleton或者prototype两种方式。不想多说了，我觉得你对框架了解得还不够深。
你说的那些我也懂，书上都是那么说的，你想想为什么Servlet不建议定义成员变量？和struts1中的action一个道理
而struts2中因为包含成员变量，这是与struts1的区别之一，为此，再将action声明为单例模式已然不合适了，
所以才针对每个请求实例化一次，原因就是你说的线程安全的问题，
如果用单例模式，必须使用threadlocal类
对于Struts2来说，可以包含成员变量才是它的根本，所以它放弃了单例模式
我说的行不行，是针对框架设计来说的，从技术的角度上讲当然没有什么不可能
你以为呢？
深刻~~~~~~~~~~~
在《关于Java开发不明白的一些问题》中提及Struts1和Struts2，
只不过是用来作为讨论解耦的一个例子而已,我没有从整体上评价孰优孰劣
事实上,我也是先接触了Struts2后来才看的Struts1，
看到一些把Struts2拿来膜拜，我觉得自己是不是应该好好反思一下?
凡是做过JavaWeb开发的莫不了解MVC,凡是了解MVC的莫不了解Struts
纵观java世界里的Web框架,无论形式上如何变化,其本质上却是大抵相同的
所有,不要见人就问你懂不懂某某框架啊
懂框架不如懂原理,举一反三的道理人人都懂,却不是人人都能做的到
那么,那么多的框架,本质是什么呢?相同点又在哪里呢?
其实,无论外表搞得多炫,核心还是Servlet驱动的
而驱动的模型无外乎两种:请求响应驱动和事件响应驱动
我知道的,基于事件驱动的框架有Seam,
而基于请求响应驱动的就很多了,如Struts1和2,XWebWork,Spring-MVC等等
脱离了这些框架之后,所有的东西都能有Servlet实现
而Servlet+JSP+JavaBean就是一个无任何框架的开发模式
这里看好了,JavaBean框架无关的,而JSP现在有多有视图模型可以替代
那么,框架的主要功能是什么呢?,就是取代Servlet的逻辑控制作用
在Struts中,取代Servlet的对象就是Action,
下面,我们来看看Struts1和2中Action的角色有什么不同
在MVC框架中,M作为数据承载的对象,是有状态的,
具体讲,就是一个对象有属性,通过方法的调用来改变属性的值,从而达到状态变化
如果M纯粹作为数据载体的话,那么它的状态变化需要外界来驱动
就像一辆车子,车子本身是不能动的,需要由人来驾驶
在String1中,M就是ActionForm,而C就是Action,
通过Action调用方法并将ActionForm作为参数,来改变ActionForm的属性,
从而完成对客户端的响应
这里,Struts1的一个弊端就是这个JavaBean不是框架无关的,而是需要继承框架的一个基类
为了解决这个弊端,到了Struts2,Struts已经完全否定了自己,转投XWebWork的怀抱
我想说的是,这个自我否定,做得有点过火了,因为你从本质上将还是一个Web框架,
我们将耦合与内聚,你把粒度放大,其实耦合不过就是更大粒度的内聚
不是解耦不是为了方便,耦合的越紧效率越高,使用越方便,这就是集成,它的缺点就是不适应变化
那么我就说了,Struts2你再怎么变化就有一点是不需要变化的,
那就是——你究竟不过是个Web框架
我们来看看Struts2的Action，
第一，action本身包含业务逻辑的数据，那么它承担着M的角色
第二，action还能执行方法，改变自身的属性，那么它同时承担这C的角色
所以在Struts2中，action是自驱动的，不需要外界的干涉，便能改变自己的状态
这就像一辆无人驾驶的汽车一样，有些人觉得这很爽，有些人觉得很不爽？为什么呢？
——因为有些人喜欢开车，有些人不喜欢开车！
也就是有些人喜欢自己控制代码的流程，而有些人却想什么都交给框架做
基于以上的比较，我们来看看Struts1和Struts2有关解耦的问题
可以这么说，即使什么框架都不用，纯粹的Servlet+Jsp+Bean都能解耦，
所以没有什么框架不能解构的，如果你觉得不能解耦，那么就是你的代码设计本身有问题？
还是举个例子吧：
有人说，Struts1中action方法里带有Request和Response对象，无法解耦
我想说，至少有两种办法来解耦：
第一，自己创建Request和Response对象对象
这两个对象不过就是个接口声明,你完全可以有的实现,如果使用了适配器模式,那就更方便了
第二,在需要从Request对象获取数据的地方,将变量提升为参数或者属性同样可以解耦
还是一点想说的是,解耦不过是个概念性的东西,主要是为了应对变化,
但是,现在好多人把解耦简单地理解为,我不继承你的类或接口,就是解耦,
这真是匪夷所思!!!!
再举个例子吧,看看所谓的Struts2的解耦~
对于一个数据对象,它就是一个Bean,
这个Bean是框架无关的,它只包含了业务数据,我们可以将它用到各个框架中,
但是在Struts2中,它是一个action,同样包含了业务数据,但是同时包含了业务逻辑
因为它没有继承Struts2的任何接口和类,你认为它是解耦的,
但是当你把它用到其他框架中,有用的只是它的数据,而不是它的处理方法,因为它的处理方法只有Struts2的框架有用
这种解耦的代价就是代码污染,因为一个数据对象到处包含着不能共享的业务逻辑处理方法
把这种情况放在Struts1中,你可能会说它需要继承一个ActionForm类,
不错,的确如此,但是仅仅这一个类,就可以让你免除那么无谓的代码污染
因为这个类属于Struts,你就认为耦合了,如果在JDK中,你就不那么觉得了?
JDK中的类和我们自己编写的类有区别么?除了身份不同罢了~~~~~~~~~
到了这里,也许你会说,我可以对业务数据进行包装,进行从Action到JavaBean的转换,
那么你可以这样,同样Struts1中也可以进行ActionForm到JavaBean的转换,
所以本质上的解耦根本不是由Struts2来提供的,而是在于你的代码设计
发这个帖子的目的,就是想澄清一下Struts2所谓的解耦,不过玩的概念而已
当然你以可以喜欢它,毕竟比Struts1开发更方便
也可不喜欢它,因为它让你更远离技术
在人家玩概念的时候,也许我们更需要明白的是概念表面下所隐藏的实质,
也许这实质不是我说的这样,但是学习不就是一个不断思考的过程么?
PS:
框架自然有它的好处，不然不会有那么多人用它，但是它无形中造成了程序员价值的贬值
个人的愚论：越是底层的知识，有效期就越长;越是上层的东西,依赖性越强~~~~~~~~~~
从更宏观的角度来讲，整天跟着框架跑，奔波于了解和掌握框架的最新特性，
倒不如研究一下框架本身隐藏的技术手段，能够做到以不变应万变
一旦哪天框架的开发者宣布不再维护了，那么,
是否你的学习就到了尽头了呢？还是继续寻找新的替代者？
18 楼
peterwei
2011-03-11
nianien 写道
peterwei 写道
前面话太多，没有全看完。应该写你言论的重点并标注，没人喜欢看这长篇大论。
这个是赞同的。
开发者的价值不在于使不使用框架，而在于自身的不断总结和成长，并不仅仅是技术方面。
这个观点是对的。工具和框架只是提高我们开发效率的一种手段。
1.在Struts中，Action是Model层，更准确。
至于你说的什么Struts1中的ActionForm,Struts2中的pojo model是Model是不够精确的；还有Action是Controller是Action也是不精确的。这二者在于我眼里都是大Model，包括Action中调用后台的Service,应该都统归于MVC框架中的广义Model。
2.至于Controller应该是Struts1中的ActionServlet,Struts2中的FilterDispatcher.
3.view是jsp,jstl,freemarker,velocity这些东西。对应struts2就是result返回的东东。
又废话了一堆。哈哈。
引用
在人家玩概念的时候,也许我们更需要明白的是概念表面下所隐藏的实质,
也许这实质不是我说的这样,但是学习不就是一个不断思考的过程么?
也许这实质不是我说的这样,但是学习不就是一个不断思考的过程么?
这个是赞同的。
引用
框架自然有它的好处，不然不会有那么多人用它，但是它无形中造成了程序员价值的贬值
个人的愚论：越是底层的知识，有效期就越长;越是上层的东西,依赖性越强~~~~~~~~~~
个人的愚论：越是底层的知识，有效期就越长;越是上层的东西,依赖性越强~~~~~~~~~~
开发者的价值不在于使不使用框架，而在于自身的不断总结和成长，并不仅仅是技术方面。
引用
从更宏观的角度来讲，整天跟着框架跑，奔波于了解和掌握框架的最新特性，
倒不如研究一下框架本身隐藏的技术手段，能够做到以不变应万变
一旦哪天框架的开发者宣布不再维护了，那么,
是否你的学习就到了尽头了呢？还是继续寻找新的替代者？
倒不如研究一下框架本身隐藏的技术手段，能够做到以不变应万变
一旦哪天框架的开发者宣布不再维护了，那么,
是否你的学习就到了尽头了呢？还是继续寻找新的替代者？
这个观点是对的。工具和框架只是提高我们开发效率的一种手段。
1.在Struts中，Action是Model层，更准确。
至于你说的什么Struts1中的ActionForm,Struts2中的pojo model是Model是不够精确的；还有Action是Controller是Action也是不精确的。这二者在于我眼里都是大Model，包括Action中调用后台的Service,应该都统归于MVC框架中的广义Model。
2.至于Controller应该是Struts1中的ActionServlet,Struts2中的FilterDispatcher.
3.view是jsp,jstl,freemarker,velocity这些东西。对应struts2就是result返回的东东。
又废话了一堆。哈哈。
至于Controller应该是Struts1中的ActionServlet,Struts2中的FilterDispatcher
这句你说的挺对的,但是这些本来就是Servlet的东西,框架不使用它就无法实现,
action 的出现难道不是为了替代Servlet么?
框架替代servlet有什么不好吗？框架能省去你很多要做，要考虑的东西，让你专注于业务需求方面的东西。也许框架封装了很多技术性的东西，你可能会想这造成开发人员的贬值，但事实不是这样的。公司里面更值钱的是那些业务需求人员，是那些管理，架构和设计人员，而不是开发人员。
从高层的角度来说：有一套统一的东西（不管是开源还是自已实现的内部框架），可以形成规范，利于大家快速开发，也利于统一管理。底层的爱跑路就跑路，我不管，我再招，反正懂框架的人好招。
从个人的角度来说：反正是重复劳动，能省我力气最好，本来就是混口饭吃，省一事，赶紧回家看电视玩游戏多好。至于上进的同学，可以抽出更多的时间做自已感兴趣的事。ps:玩游戏也是上进的，哈哈。
19 楼
紧急下潜
2011-03-11
nianien 写道
紧急下潜 写道
我来说点
1. 我想知道楼主到底有几年开发经验？
我的初步判断应该不会超过3年
2. 我想知道楼主到底做过多少个项目，从事过的每个项目的人员和代码量有多少？
其他的我不好说，但是项目代码量我估计不会太大
3. 你之前说自己看过struts 1 2和spring的源码，但是你有没有理解到他们的原理那？
我的初步判断是楼主没有
如果你知道spring这个框架是怎么诞生的，你就不会如此肤浅了。
再说一次，就冲你之前的那个帖子被评为良好，就看出来了javaeye真的没落的
1. 我想知道楼主到底有几年开发经验？
我的初步判断应该不会超过3年
2. 我想知道楼主到底做过多少个项目，从事过的每个项目的人员和代码量有多少？
其他的我不好说，但是项目代码量我估计不会太大
3. 你之前说自己看过struts 1 2和spring的源码，但是你有没有理解到他们的原理那？
我的初步判断是楼主没有
如果你知道spring这个框架是怎么诞生的，你就不会如此肤浅了。
再说一次，就冲你之前的那个帖子被评为良好，就看出来了javaeye真的没落的
那些用项目大小和代码量来衡量人的,真的很无语,我最鄙视~~~~~~~
哪一个框架的代码量不比项目的代码量小?但是哪个才是精华?你懂的~
有的人编了一辈子代码,只不过会用几个框架而已
有的人一行代码不写,照样能成为专家
写和读和思考和创造都是有区别的~~~~~~~~
说实话，你所说的这些我从你身上都没看出来，问个很简单问题
Q: 有两个方案1.servlet + javabean 方案2.Struts2或者其他类似框架
如果你的业务逻辑从十几个数量级上升到上百个甚至上千个数量级的时候你应该选择哪个方案，为什么？
20 楼
nianien
2011-03-11
紧急下潜 写道
nianien 写道
紧急下潜 写道
我来说点
1. 我想知道楼主到底有几年开发经验？
我的初步判断应该不会超过3年
2. 我想知道楼主到底做过多少个项目，从事过的每个项目的人员和代码量有多少？
其他的我不好说，但是项目代码量我估计不会太大
3. 你之前说自己看过struts 1 2和spring的源码，但是你有没有理解到他们的原理那？
我的初步判断是楼主没有
如果你知道spring这个框架是怎么诞生的，你就不会如此肤浅了。
再说一次，就冲你之前的那个帖子被评为良好，就看出来了javaeye真的没落的
1. 我想知道楼主到底有几年开发经验？
我的初步判断应该不会超过3年
2. 我想知道楼主到底做过多少个项目，从事过的每个项目的人员和代码量有多少？
其他的我不好说，但是项目代码量我估计不会太大
3. 你之前说自己看过struts 1 2和spring的源码，但是你有没有理解到他们的原理那？
我的初步判断是楼主没有
如果你知道spring这个框架是怎么诞生的，你就不会如此肤浅了。
再说一次，就冲你之前的那个帖子被评为良好，就看出来了javaeye真的没落的
那些用项目大小和代码量来衡量人的,真的很无语,我最鄙视~~~~~~~
哪一个框架的代码量不比项目的代码量小?但是哪个才是精华?你懂的~
有的人编了一辈子代码,只不过会用几个框架而已
有的人一行代码不写,照样能成为专家
写和读和思考和创造都是有区别的~~~~~~~~
说实话，你所说的这些我从你身上都没看出来，问个很简单问题
Q: 有两个方案1.servlet + javabean 方案2.Struts2或者其他类似框架
如果你的业务逻辑从十几个数量级上升到上百个甚至上千个数量级的时候你应该选择哪个方案，为什么？
一般情况下,都是自己开发框架,纵观那些框架,本质上有什么区别?
业务逻辑再怎么上升,那些框架还不是只用一个Servlet搞定?你能给我举个例子,哪个不是?
动不动就呈XX数量级上升,业务逻辑的数据量级在你进行需求分析的时候就确定了
21 楼
nianien
2011-03-11
peterwei 写道
nianien 写道
action 的出现难道不是为了替代Servlet么?
框架替代servlet有什么不好吗？框架能省去你很多要做，要考虑的东西，让你专注于业务需求方面的东西。也许框架封装了很多技术性的东西，你可能会想这造成开发人员的贬值，但事实不是这样的。公司里面更值钱的是那些业务需求人员，是那些管理，架构和设计人员，而不是开发人员。
从高层的角度来说：有一套统一的东西（不管是开源还是自已实现的内部框架），可以形成规范，利于大家快速开发，也利于统一管理。底层的爱跑路就跑路，我不管，我再招，反正懂框架的人好招。
从个人的角度来说：反正是重复劳动，能省我力气最好，本来就是混口饭吃，省一事，赶紧回家看电视玩游戏多好。至于上进的同学，可以抽出更多的时间做自已感兴趣的事。ps:玩游戏也是上进的，哈哈。
呵呵,我从来没有做替代Servlet不好,我只是不想让有些人混淆概念,欺世盗名
我不是说Struts2的Action不好,它的每个请求对应每个Action实例,并不是像它宣传的那样,怎么怎么比单例模式好,
而是它不得不那样实现!
有人讲过Struts2不能用单例模式的原因么?不是它不想用,而是用不了~~
22 楼
sarstime
2011-03-11
lqtcts 写道
看完楼主的写的表面上振振有词，其实全部在扯淡。MVC理解不到位，解耦思想也不到位，对框架的认识也不到位。
“在String1中,M就是ActionForm,而C就是Action,
”
我就不知道你读过struts的源码没有，action是控制器？Action是模型？佩服啊！！！
“Servlet+JSP+JavaBean就是一个无任何框架的开发模式
”
又在说些火星的语言，是Servlet+JSP+JavaBean不是mvc模式么，楼主你在说笑吧？
“如果在JDK中,你就不那么觉得了?
JDK中的类和我们自己编写的类有区别么?除了身份不同罢了~~~~~~~~~
”
又说些搞笑的的话，JDK有的，你还需要写么？
还有，楼主说自建一个request，response就可以解耦合，真不知道你的脑子里想的啥...
楼主就是一个新手，不想多说，跟你多说你肯定会反驳，
“在String1中,M就是ActionForm,而C就是Action,
”
我就不知道你读过struts的源码没有，action是控制器？Action是模型？佩服啊！！！
“Servlet+JSP+JavaBean就是一个无任何框架的开发模式
”
又在说些火星的语言，是Servlet+JSP+JavaBean不是mvc模式么，楼主你在说笑吧？
“如果在JDK中,你就不那么觉得了?
JDK中的类和我们自己编写的类有区别么?除了身份不同罢了~~~~~~~~~
”
又说些搞笑的的话，JDK有的，你还需要写么？
还有，楼主说自建一个request，response就可以解耦合，真不知道你的脑子里想的啥...
楼主就是一个新手，不想多说，跟你多说你肯定会反驳，
说就好好说，要么就别说，受不了这种人。你到位，你倒是引经据典啊。大尾巴狼，玩深沉。
23 楼
peterwei
2011-03-11
nianien 写道
peterwei 写道
nianien 写道
action 的出现难道不是为了替代Servlet么?
框架替代servlet有什么不好吗？框架能省去你很多要做，要考虑的东西，让你专注于业务需求方面的东西。也许框架封装了很多技术性的东西，你可能会想这造成开发人员的贬值，但事实不是这样的。公司里面更值钱的是那些业务需求人员，是那些管理，架构和设计人员，而不是开发人员。
从高层的角度来说：有一套统一的东西（不管是开源还是自已实现的内部框架），可以形成规范，利于大家快速开发，也利于统一管理。底层的爱跑路就跑路，我不管，我再招，反正懂框架的人好招。
从个人的角度来说：反正是重复劳动，能省我力气最好，本来就是混口饭吃，省一事，赶紧回家看电视玩游戏多好。至于上进的同学，可以抽出更多的时间做自已感兴趣的事。ps:玩游戏也是上进的，哈哈。
呵呵,我从来没有做替代Servlet不好,我只是不想让有些人混淆概念,欺世盗名
我不是说Struts2的Action不好,它的每个请求对应每个Action实例,并不是像它宣传的那样,怎么怎么比单例模式好,
而是它不得不那样实现!
有人讲过Struts2不能用单例模式的原因么?不是它不想用,而是用不了~~
什么叫它不得不那样实现，什么用不了。用不用单例，在于用它的人想怎么样。
servlet以及struts1，在多线程环境下，对于成员变量的使用是不安全的。这也应该是struts2默认不是singleton，而是prototype的原因。一般struts2的实例都是spring容器管理，scope可以配成singleton或者prototype两种方式。不想多说了，我觉得你对框架了解得还不够深。
24 楼
volking
2011-03-11
楼主你太差劲了
在String1中,M就是ActionForm,而C就是Action明显有很大的问题。
在String1中,M就是ActionForm,而C就是Action明显有很大的问题。
25 楼
紧急下潜
2011-03-11
nianien 写道
紧急下潜 写道
nianien 写道
紧急下潜 写道
我来说点
1. 我想知道楼主到底有几年开发经验？
我的初步判断应该不会超过3年
2. 我想知道楼主到底做过多少个项目，从事过的每个项目的人员和代码量有多少？
其他的我不好说，但是项目代码量我估计不会太大
3. 你之前说自己看过struts 1 2和spring的源码，但是你有没有理解到他们的原理那？
我的初步判断是楼主没有
如果你知道spring这个框架是怎么诞生的，你就不会如此肤浅了。
再说一次，就冲你之前的那个帖子被评为良好，就看出来了javaeye真的没落的
1. 我想知道楼主到底有几年开发经验？
我的初步判断应该不会超过3年
2. 我想知道楼主到底做过多少个项目，从事过的每个项目的人员和代码量有多少？
其他的我不好说，但是项目代码量我估计不会太大
3. 你之前说自己看过struts 1 2和spring的源码，但是你有没有理解到他们的原理那？
我的初步判断是楼主没有
如果你知道spring这个框架是怎么诞生的，你就不会如此肤浅了。
再说一次，就冲你之前的那个帖子被评为良好，就看出来了javaeye真的没落的
那些用项目大小和代码量来衡量人的,真的很无语,我最鄙视~~~~~~~
哪一个框架的代码量不比项目的代码量小?但是哪个才是精华?你懂的~
有的人编了一辈子代码,只不过会用几个框架而已
有的人一行代码不写,照样能成为专家
写和读和思考和创造都是有区别的~~~~~~~~
说实话，你所说的这些我从你身上都没看出来，问个很简单问题
Q: 有两个方案1.servlet + javabean 方案2.Struts2或者其他类似框架
如果你的业务逻辑从十几个数量级上升到上百个甚至上千个数量级的时候你应该选择哪个方案，为什么？
一般情况下,都是自己开发框架,纵观那些框架,本质上有什么区别?
业务逻辑再怎么上升,那些框架还不是只用一个Servlet搞定?你能给我举个例子,哪个不是?
动不动就呈XX数量级上升,业务逻辑的数据量级在你进行需求分析的时候就确定了
面对你的观点真的很无语，我就再问的直接一点，楼主写过unit test吗？会写unit test吗？
26 楼
wsdsgfuqiang
2011-03-11
框架的主要功能是什么呢?,就是取代Servlet的逻辑控制作用 嗯 有道理
27 楼
moisen
2011-03-11
楼主说的框架使得程序员贬值，这句话相当赞同，一个框架要不了几天就上手了，学习成本低，开发效率还高，这就是往往领导都喜欢用框架，因为领导都想用更短的时间创造更多的RMB。
28 楼
guoyingqiang
2011-03-11
java是面向对象的。面向对象是为了更方便我们开发的。框架不框架无关紧要的。项目所需才是王道的。思想是要掌握的。java退出历史舞台也是迟早的。别忘了写代码最初的快乐就好了。
29 楼
wuliaolll
2011-03-11
我觉得一个人的能力不能以项目开发经验去衡量。
项目中用框架提高效率无可厚非。
写代码思考很重要，不管你是热衷于框架还是底层。
项目中用框架提高效率无可厚非。
写代码思考很重要，不管你是热衷于框架还是底层。
30 楼
nianien
2011-03-11
紧急下潜 写道
nianien 写道
紧急下潜 写道
nianien 写道
紧急下潜 写道
我来说点
1. 我想知道楼主到底有几年开发经验？
我的初步判断应该不会超过3年
2. 我想知道楼主到底做过多少个项目，从事过的每个项目的人员和代码量有多少？
其他的我不好说，但是项目代码量我估计不会太大
3. 你之前说自己看过struts 1 2和spring的源码，但是你有没有理解到他们的原理那？
我的初步判断是楼主没有
如果你知道spring这个框架是怎么诞生的，你就不会如此肤浅了。
再说一次，就冲你之前的那个帖子被评为良好，就看出来了javaeye真的没落的
1. 我想知道楼主到底有几年开发经验？
我的初步判断应该不会超过3年
2. 我想知道楼主到底做过多少个项目，从事过的每个项目的人员和代码量有多少？
其他的我不好说，但是项目代码量我估计不会太大
3. 你之前说自己看过struts 1 2和spring的源码，但是你有没有理解到他们的原理那？
我的初步判断是楼主没有
如果你知道spring这个框架是怎么诞生的，你就不会如此肤浅了。
再说一次，就冲你之前的那个帖子被评为良好，就看出来了javaeye真的没落的
那些用项目大小和代码量来衡量人的,真的很无语,我最鄙视~~~~~~~
哪一个框架的代码量不比项目的代码量小?但是哪个才是精华?你懂的~
有的人编了一辈子代码,只不过会用几个框架而已
有的人一行代码不写,照样能成为专家
写和读和思考和创造都是有区别的~~~~~~~~
说实话，你所说的这些我从你身上都没看出来，问个很简单问题
Q: 有两个方案1.servlet + javabean 方案2.Struts2或者其他类似框架
如果你的业务逻辑从十几个数量级上升到上百个甚至上千个数量级的时候你应该选择哪个方案，为什么？
一般情况下,都是自己开发框架,纵观那些框架,本质上有什么区别?
业务逻辑再怎么上升,那些框架还不是只用一个Servlet搞定?你能给我举个例子,哪个不是?
动不动就呈XX数量级上升,业务逻辑的数据量级在你进行需求分析的时候就确定了
面对你的观点真的很无语，我就再问的直接一点，楼主写过unit test吗？会写unit test吗？
看你这话说的,我从接触java的第一天就写unit test了
而且,java根本就没有学习过,看看jdk api直接就用了
31 楼
starmb
2011-03-11
<p>哦，也难怪大多数人都笑而不语的飘过。因为大家都很明白楼主到底在什么位置上。</p>
32 楼
nianien
2011-03-12
peterwei 写道
nianien 写道
peterwei 写道
nianien 写道
action 的出现难道不是为了替代Servlet么?
框架替代servlet有什么不好吗？框架能省去你很多要做，要考虑的东西，让你专注于业务需求方面的东西。也许框架封装了很多技术性的东西，你可能会想这造成开发人员的贬值，但事实不是这样的。公司里面更值钱的是那些业务需求人员，是那些管理，架构和设计人员，而不是开发人员。
从高层的角度来说：有一套统一的东西（不管是开源还是自已实现的内部框架），可以形成规范，利于大家快速开发，也利于统一管理。底层的爱跑路就跑路，我不管，我再招，反正懂框架的人好招。
从个人的角度来说：反正是重复劳动，能省我力气最好，本来就是混口饭吃，省一事，赶紧回家看电视玩游戏多好。至于上进的同学，可以抽出更多的时间做自已感兴趣的事。ps:玩游戏也是上进的，哈哈。
呵呵,我从来没有做替代Servlet不好,我只是不想让有些人混淆概念,欺世盗名
我不是说Struts2的Action不好,它的每个请求对应每个Action实例,并不是像它宣传的那样,怎么怎么比单例模式好,
而是它不得不那样实现!
有人讲过Struts2不能用单例模式的原因么?不是它不想用,而是用不了~~
什么叫它不得不那样实现，什么用不了。用不用单例，在于用它的人想怎么样。
servlet以及struts1，在多线程环境下，对于成员变量的使用是不安全的。这也应该是struts2默认不是singleton，而是prototype的原因。一般struts2的实例都是spring容器管理，scope可以配成singleton或者prototype两种方式。不想多说了，我觉得你对框架了解得还不够深。
你说的那些我也懂，书上都是那么说的，你想想为什么Servlet不建议定义成员变量？和struts1中的action一个道理
而struts2中因为包含成员变量，这是与struts1的区别之一，为此，再将action声明为单例模式已然不合适了，
所以才针对每个请求实例化一次，原因就是你说的线程安全的问题，
如果用单例模式，必须使用threadlocal类
对于Struts2来说，可以包含成员变量才是它的根本，所以它放弃了单例模式
我说的行不行，是针对框架设计来说的，从技术的角度上讲当然没有什么不可能
你以为呢？
33 楼
huanglongje
2011-03-12
话说，楼主不过是有感而发而已，大家互相评论一下，也无可厚非，神马都是浮云而已！
又说，对与不对，都不过是知识掌握的一个阶段而已，而且事事无常，对与错都是相对而已，没啥绝对的！
还说，等你想说的时候其实是你不懂的时候，等你懂的时候，其实也没有想说的了！
又说，对与不对，都不过是知识掌握的一个阶段而已，而且事事无常，对与错都是相对而已，没啥绝对的！
还说，等你想说的时候其实是你不懂的时候，等你懂的时候，其实也没有想说的了！
34 楼
nianien
2011-03-12
huanglongje 写道
话说，楼主不过是有感而发而已，大家互相评论一下，也无可厚非，神马都是浮云而已！
又说，对与不对，都不过是知识掌握的一个阶段而已，而且事事无常，对与错都是相对而已，没啥绝对的！
还说，等你想说的时候其实是你不懂的时候，等你懂的时候，其实也没有想说的了！
又说，对与不对，都不过是知识掌握的一个阶段而已，而且事事无常，对与错都是相对而已，没啥绝对的！
还说，等你想说的时候其实是你不懂的时候，等你懂的时候，其实也没有想说的了！
深刻~~~~~~~~~~~
35 楼
jackra
2011-03-12
事实上我在读阁下的《关于Java开发不明白的一些问题》就想回帖了。不过当时注册不到3天不能回复。呵呵。
你的观点我很支持。但有些地方有点偏激。
首先，在考虑使用什么框架或者工具的时候，我们应该首先考虑的是什么？是工具或者框架能给我们带来什么改变。
基于以上的理论，再来看struts。
struts的出现在早期给大家带来了框架理念。在满脑子都是jsp和servlet的编程理念中，它带来了一种新的思维方式，就是把所有页面都要做的事情，放在一起，然后找几个文件，把那些混乱的东西，做标注，方便寻找线索。在早期的页面与逻辑和资源调用混杂的编程环境下，这些东西是先进的。
然而对于当下的环境，是否struts还有他的意义呢？最少我个人并不看好struts。
你说的很对，我不看好struts的本身就是因为他把view也放在了自己的职权范围。服务器本身不仅仅是c和m，而且还包含了v的概念。除此之外，struts还给我们带来了什么？它本身试图从复杂混乱的页面编程中寻求一种统一的规范化的开发方式，但是结果却与初衷关系不大。要写页面？依旧还是要写页面，只不过增加了几个标签的扩展，有的时候这些标签反而导致很多人大脑混乱；需要在页面关系间建立脉络？结果确实混乱的配置文件；想要在混乱的调用之间把逻辑与页面本身分离？结果却是更加混乱的配置文件加上破碎的逻辑程序与破碎的页面集合。
总的来说，struts的初衷是从混乱之中试图寻找一种统一，来结束混乱的局面，让混乱成为有规律的东西。至少在混乱的环境下，他是成功的，并且做到了一些什么。
但是，认识与环境的发展是变化的。在当下的环境下，这样的模式本身已经是一种out的东西。相对来说我更加欣赏ajax的规划风格。额。。先不讨论技术上的东西。毕竟ajax我还没深入的研究。
从本质上来说，LZ提出的问题很值得欣赏。了到底工具和框架给我们带来了什么？基于此目的地学习，是有效的。比盲目的去追捧潮流，追捧迎合性面试要更加深入与现实。
在下也很厌烦随便一个什么公司的面试就要去问SSH一类的东西。使用SSH本身就证明了技术和理念的落后与食古不化。
你的观点我很支持。但有些地方有点偏激。
首先，在考虑使用什么框架或者工具的时候，我们应该首先考虑的是什么？是工具或者框架能给我们带来什么改变。
基于以上的理论，再来看struts。
struts的出现在早期给大家带来了框架理念。在满脑子都是jsp和servlet的编程理念中，它带来了一种新的思维方式，就是把所有页面都要做的事情，放在一起，然后找几个文件，把那些混乱的东西，做标注，方便寻找线索。在早期的页面与逻辑和资源调用混杂的编程环境下，这些东西是先进的。
然而对于当下的环境，是否struts还有他的意义呢？最少我个人并不看好struts。
你说的很对，我不看好struts的本身就是因为他把view也放在了自己的职权范围。服务器本身不仅仅是c和m，而且还包含了v的概念。除此之外，struts还给我们带来了什么？它本身试图从复杂混乱的页面编程中寻求一种统一的规范化的开发方式，但是结果却与初衷关系不大。要写页面？依旧还是要写页面，只不过增加了几个标签的扩展，有的时候这些标签反而导致很多人大脑混乱；需要在页面关系间建立脉络？结果确实混乱的配置文件；想要在混乱的调用之间把逻辑与页面本身分离？结果却是更加混乱的配置文件加上破碎的逻辑程序与破碎的页面集合。
总的来说，struts的初衷是从混乱之中试图寻找一种统一，来结束混乱的局面，让混乱成为有规律的东西。至少在混乱的环境下，他是成功的，并且做到了一些什么。
但是，认识与环境的发展是变化的。在当下的环境下，这样的模式本身已经是一种out的东西。相对来说我更加欣赏ajax的规划风格。额。。先不讨论技术上的东西。毕竟ajax我还没深入的研究。
从本质上来说，LZ提出的问题很值得欣赏。了到底工具和框架给我们带来了什么？基于此目的地学习，是有效的。比盲目的去追捧潮流，追捧迎合性面试要更加深入与现实。
在下也很厌烦随便一个什么公司的面试就要去问SSH一类的东西。使用SSH本身就证明了技术和理念的落后与食古不化。
36 楼
carlkkx
2011-03-12
凡是了解MVC的莫不了解Struts
————————————————
胡说
————————————————
胡说
37 楼
aws
2011-03-12
其实struts1的思想继承者不是struts2，而是spring mvc