- 浏览: 143394 次
- 性别:
- 来自: 北京
最新评论
-
cherishlive:
charlth.li@hotmail.com 同求 谢谢
通过jsp标签封装的列表组件 -
xiaoll880214:
您好!利用你贴的decodeQuotedPrintable方法 ...
实现MHT文件格式的解析和内容抽取 -
zhenrs:
可以把ApplicationContext贴出来不
JBPM与SPRING事务整合之深度历险 -
cllstudy:
您好,急需lucene对mht解析的parse,能发源代码给我 ...
实现MHT文件格式的解析和内容抽取 -
terryisme:
terryisme@126.com多谢.
通过jsp标签封装的列表组件
前面提出了关于SSH架构中struts的鸡肋问题,大家也给出了热情洋溢的意见,表达了各自的观点:
原帖链接: http://www.iteye.com/post/1027849?page=1
大家对于实战中存在的这样一种现状还是有共识的,确实存在开发效率的问题。如何解决?右派认为忍气吞声吧,不就是多写点代码而已,没什么大不了;左派很激烈nostruts吧struts2吧.....当然还有理性的声音,改革吧....
当然说struts鸡肋也有点夸张只是为了让大家兴奋起来才如此称呼而已。客观的讲struts本身的架构设计是符合<J2EE核心模式>的,作为展现层的基础架构,struts很好的完成了自己的使命,在j2ee混沌刚开劈疆拓土的时代这面大旗的咧咧风声功勋卓著。
--------------------------
言归正传:
我的意见是:既然他们贫血,而且应该贫血,那么就让他们彻底贫血彻底消失,起码在某些场景下消失,省得这样的代码影响市容影响和谐,提高各位键盘的寿命。
做法就是对这些贫血对象作封装,不要在开发中频繁写这样的对象,而且封装其实很简单的。同时封装时只针对我们说的简单场景,不阉割struts功能,对于复杂点的例如依赖servlet接口的一些操作依然可以按照传统的action处理。
--------------------------
- Nice Struts 效果,Struts配置:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" "http://struts.apache.org/dtds/struts-config_1_2.dtd"> <struts-config> <form-beans> <form-bean name="niceForm" type="com.*****.nstruts.NiceForm" /> </form-beans> <action-mappings> <action path="/addBook" parameter="bookManage.addBook(book)"----------------- 1 scope="request" type="com.****.nstruts.NiceAction"---------------------------------------------- ------ 2 name="niceForm">--------------------------------------------------------------- -------3 <forward name="success" path="/getAllBooks.do"></forward> <forward name="fail" path="/***.jsp"></forward> </action> <action path="/delBook" parameter="bookManage.delBook(bookid)" scope="request" type="com.****.nstruts.NiceAction" name="niceForm"> <forward name="success" path="/getAllBooks.do"></forward> </action> <action path="/modifyBook" parameter="bookManage.modifyBook(book,oldId)" scope="request" type="com.***.nstruts.NiceAction" name="niceForm"> <forward name="fail" path="/book_modify.jsp"></forward> <forward name="success" path="/infoBook.do"></forward> </action> <action path="/getAllBooks" parameter="bookManage.getAllBooks():books" scope="request" type="com.***.nstruts.NiceAction" name="niceForm"> <forward name="success" path="/book_all.jsp"></forward> </action> </action-mappings> </struts-config>
不同指出就是上面的1/2/3:
首先通过parameter指明需要执行的业务层方法,可以是多个业务方法;
其次指定使用基础的NiceForm(开发时不需要自己实现)
最后是指定基础的NiceAction(开发时不需要自己实现)
(需要说明的是在这个配置文件里完全可以混用传统的自定义的action/form)
2。Nstruts效果之jsp页面
<html:form action="addBook.do" method="post"> <br> <table border=0 cellpadding=1 cellspacing=1 class="query_table" style="width: 60%" align="center"> <tr> <th colspan="10"> <div align='left'> <b>图书登记</b> </div> </th> </tr> <tr> <th> 书名 </th> <td> <html:text property="$(book.name)" size="70"/> </td> </tr> <tr> <th> 出版社 </th> <td> <html:text property="$(book.publisher)" size="70"/> </td> </tr> <tr> <th> 作者 </th> <td> <html:text property="$(book.author)" size="70"/> </td> </tr> <tr> <th> 单价(分) </th> <td> <html:text property="$(book.price)" size="70"/> </td> </tr> <tr> <th> 备注 </th> <td> <html:textarea property="$(book.memo)"/> </td> </tr> <tr> <th> 发行日期 </th> <td> <html:text property="$(book.born)" size="70" value="2008-04-23"/> </td> </tr> </table> <table width="60%" align="center"> <tr> <td align="center"> <br> <input type="button" class="btn4" value="提 交" onclick="subform()"> <input type="button" class="btn4" value="返 回" onclick="goBack();"> </td> </tr> </table> <br> </html:form>
唯一的不同在于属性引用需要$()一下,因为目前使用的MapForm的形式扩展actionform了,高手一定会想到NiceForm中一定定义了一个get$()/set$(),呵呵。这个$其实可以省略,方法就是上帖中大家提到的lazyValidateForm。
3.service层一如既往,目前的限制是特殊的多态方法支持有问题。明眼人一看就知,反射了嘛,呵呵。。。。
END--------------------------
这样以来大家看,Struts在SSH中的角色依然,作数据的提取/展现/页面流的配置。同时没有了所说的两个鸡肋问题,struts的结构没有打乱功能没有阉割,符合一贯的开发习惯,而且足够灵活,呵呵,有点自买自夸的嫌疑。
总之罗嗦了这么多并非仅针对struts,而是为了抛砖引玉,为了说明一种技术领域的现象和个人的体会,j2ee领域的基础组件之所以灵活甚至累赘就是为了给上层的应用架构提供扩展点,struts并非鸡肋,鸡肋是我们自己的问题。在应用架构中对基础的j2ee组件/架构进行一定的扩展定制是必要的,是架构师的职责所在,只会将S/S/H一会NBCD等等堆砌在一起抑或动辄就高喊struts2吧,这样的架构师尚需要努力。
期望与各位分享在开发面向最终应用的技术框架过程中的一些创新和灵感。
Over!!!!
评论
传值用Map封装,控制逻辑用control.xml配置文件来解决。
使用注解那哪叫零配置??
使用注解只是配置转移了,呵呵,把矛盾转嫁了,如果不分场景的使用注解,可预见的未来会有针对注解的另一场口诛笔伐。个人认为技术都是又实用场景的....
我不是想引起这个讨论,因为很早以前就讨论了不知道多少次了。再说一次好了,配置文件分两种,一种是一直以来就有的例如“数据库连接属性”、“Log4j”的配置文件,而另一大类就是Struts2的页面转向逻辑和Hibernate的映射配置文件,后一大类情况还不一样,Struts2的页面转向逻辑基本属于“幻影需求”,而Hibernate的映射文件更多的是出于无奈,后来采用注解并兼容JPA规范后就很好用了,对与这一类的配置文件我不认为是真正的“配置文件”,用途不同而已。
所谓的“幻影需求”再重复一下,期望在需求变化时,系统不修改代码,而仅仅修改配置文件就能够轻松搞定,可能么?实际多做几个项目就知道了,这种幻影需求的可笑了。
这方面仅仅表述struts2的默认的配置文件过于重载而已,xml配置文件本身也是可以做出改变的,Spring的配置文件就是不断在演进的。
使用注解那哪叫零配置??
使用注解只是配置转移了,呵呵,把矛盾转嫁了,如果不分场景的使用注解,可预见的未来会有针对注解的另一场口诛笔伐。个人认为技术都是又实用场景的....
使用注解那哪叫零配置??
一般说的零配置就是指零XML配置文件。
注解当然是另一种配置方式,但是IDE对注解的支持远好于XML配置文件,注解本身是强类型,具有编译期检查、继承等特性,重构支持也非常好,大多数情况下配置效率也比XML方式高。
使用注解那哪叫零配置??
配置文件的出现本身上为了保持代码不变的情况下将设置集中管理,注解式配置实际上上走回分散设置的老路,简直类似于JSP中不写<% %>之后有人觉得用起来不够爽又重新拿出<% %>
以ssh的架构,dao+(biz+service)+action+view这样的结构,struts的action层完全可以虚化掉,页面转向控制交给配置文件,业务逻辑集中到service层,用一个base action类来充当中央控制引擎,根据IOC的配置调用与组装service内的业务逻辑,对数据的校验,等等,用自定的map取代request,一方面简化掉了action,另一方面也可以通过替换base action来达到不同的效果,比如输出的数据格式,可以无缝的把struts的form变成json数据,或者xml数据,或者其他什么
听起来是不是有些部分像webwork
不谋而合,这种思路适合很大一部分需求,屏蔽了诸多技术细节,拯救将劳苦大众与技术纠缠的水深火热,对于大规模快速应用层开发大有裨益。楼上一席话总结了一开始例子中对struts的封装思路,赞一个!!!
至于零配置我倒是觉得并非全无意义,零配置针对的是目下java领域配置泛滥的弊端,还是那句话:要配置还是要0配置需要根据具体的应用场景,要因地制宜”识别配置的必要性“,相互结合取长补短,灵活机动的选择。
Struts2就是webwork2。
配置文件的出现本身上为了保持代码不变的情况下将设置集中管理,注解式配置实际上上走回分散设置的老路,简直类似于JSP中不写<% %>之后有人觉得用起来不够爽又重新拿出<% %>
以ssh的架构,dao+(biz+service)+action+view这样的结构,struts的action层完全可以虚化掉,页面转向控制交给配置文件,业务逻辑集中到service层,用一个base action类来充当中央控制引擎,根据IOC的配置调用与组装service内的业务逻辑,对数据的校验,等等,用自定的map取代request,一方面简化掉了action,另一方面也可以通过替换base action来达到不同的效果,比如输出的数据格式,可以无缝的把struts的form变成json数据,或者xml数据,或者其他什么
听起来是不是有些部分像webwork
如果IDE没有良好支持get和set代码的生成,一样会有很多人骂娘直到质疑标准JavaBean规范的低开发效率。
华山论剑总是要有规则的,除非楼主你事先定好前提,例如:只讨论开发效率,不考虑其他相关成本。这样就可以了。
因为客户那里有不少环境就是不支持JDK1.5的,我们也没有办法。
-------------
我这里说的评审不是公司里的人,往往是客户那里的人,我们作为乙方如何去评判客户是否有资格做评审。
客户那里总有些自以为是的IT部的人,这是没办法的事。
----------------------------------------------------------
我们只讨论技术层面的问题,你提的这些问题提当然确实存在,但是我们是无能为力的,所以不要把这种因素纳入我们的话题,那样就大了,呵呵,华山论剑只谈剑术。
这个不可能的,就好比单考虑技术层面普元EOS的东西没什么特别不好的地方,但是公司里就是绝大部分的人不愿意做EOS相关的东西,想留住人必须高薪,这个成本必须要考虑的。再或者我认为JavaFX技术体系也不错嘛,但是想想这东西能成功么?(历史上优秀的技术最终没有成功的多了去了)
一个技术相关的成本有很多,学习成本之类的难道不考虑么?
回过头来说,客户也不会很无理的说,“我没听说过,不能用这个方案”,例如我们现在用的SpringMVC也算是不太普及的MVC框架,客户知道我们一直在用这个框架,所以不会有太多意见,有分歧早就沟通过了。但是如果我们公司突然要换框架,他们当然有询问为什么要换,理由风险等等等。
假设我说要换“Tapestry”,好,你想想他们会怎么做,首先就是google,然后旁敲侧击的问同行等各种手段来了解,而国内Tapestry的好评和成功案例并不是太多,无形中增加我们乙方的成本。
还有,比如现在有一个系统,不考虑甲方、不考虑技术学习成本、不考虑维护成本、不考虑交接成本,需要招人,马上就要开工,而这个系统既可以用存储过程、也可以J2EE(Struts2)、也可以ROR,光是一个招人成本就决定了,我一定是招J2EE(Struts2)的。
当然有了这么多假设好像没有意义,有点先有鸡还是先有蛋的问题,那就回头来说为什么国内招Struts2的好招又便宜呢?表面上看是因为很多培训学校教这个,很多公司确实也是用这个。再深究为什么会产生“表面上看到”的原因呢?间接证明Struts2确实是一个优秀的框架(即使曾经是),能够(相对的)提高生产效率、减少维护成本等,所以慢慢在国内普及(当然还有Struts1大大的功劳)。
-------------
我这里说的评审不是公司里的人,往往是客户那里的人,我们作为乙方如何去评判客户是否有资格做评审。
客户那里总有些自以为是的IT部的人,这是没办法的事。
----------------------------------------------------------
我们只讨论技术层面的问题,你提的这些问题提当然确实存在,但是我们是无能为力的,所以不要把这种因素纳入我们的话题,那样就大了,呵呵,华山论剑只谈剑术。
呵呵,有JROR嘛?比较支持这个。
要考虑新人的学习成本和学习积极性,Struts2的资料还是很多的,新人们也认为这玩意儿学了不愁找不到工作。
还有就是做方案的时候,评审方案的人都认识Struts2,其他的框架有些人就不认识。
个人觉得如果评审的人只知道struts2,其他不是很明了的话,那是没资格做评审的。
连各个框架优缺点都不清楚,怎么能去评审?
还有seam,不知道有人有什么好见地。
我最近听说银联的人开始大量采用seam框架。
我这里说的评审不是公司里的人(在我们公司这部分是我说了算的),往往是客户那里的人,我们作为乙方如何去评判甲方是否有资格做评审。
客户那里总有些自以为是的IT部(或者信息公司)的人,这是没办法的事。
至于Seam么,只要他们公司有个大牛能够搞定相关的一些攻坚问题,订好规范,没什么问题,完全可以采用。
连各个框架优缺点都不清楚,怎么能去评审?
还有seam,不知道有人有什么好见地。
我最近听说银联的人开始大量采用seam框架。
严重关切严重同意
呵呵,有JROR嘛?比较支持这个。
要考虑新人的学习成本和学习积极性,Struts2的资料还是很多的,新人们也认为这玩意儿学了不愁找不到工作。
还有就是做方案的时候,评审方案的人都认识Struts2,其他的框架有些人就不认识。
个人觉得如果评审的人只知道struts2,其他不是很明了的话,那是没资格做评审的。
连各个框架优缺点都不清楚,怎么能去评审?
还有seam,不知道有人有什么好见地。
我最近听说银联的人开始大量采用seam框架。
啊?没有不满意,我就是建议楼主这么做啊。我是想引出后续的话,这些零配置的东西其实是变相的“配”在action中,所以action这一层并不是鸡肋。
发表评论
-
回望之一:是时侯了
2009-12-13 23:18 1090时间一如即往的快,转眼间又到年未了 ... -
Crack MxGraph 破解
2009-08-23 13:32 8091JGraph是免费的! MxGraph是收费的,官方D ... -
SSH架构中的Struts似乎很鸡肋
2009-05-24 20:33 2174在基于SSH的架构中,基本的流程是这样的: 1、展现 ... -
struts的多模块配置,真滴很扯淡?
2009-05-24 00:38 948首先声明,struts1的多模块配置很好很强大 ... -
解析java web开发中的困扰(1)
2009-05-23 23:56 893诸如jsp等脚本性质的语法、基于xml的属性配置与属性注入在 ... -
Hibernate的事件和拦截器体系
2008-08-28 14:45 2037持久层框架底层的拦截器机制是对诸如Spring等业务管理 ... -
探索象棋(JAVA版) UCCI引擎
2008-07-28 17:51 1789参见图片,呵呵 -
实现Microsoft Project 的解析和内容抽取
2008-05-13 09:55 2179文本内容提取: 使用net.sf.mpxj 的工具提取 ... -
论权限模型
2008-05-06 09:38 1076权限模型多种多样,包含各种教条和方法论,但在实践中真正 ... -
使用JEdit打造自己的IDE
2008-04-06 11:26 2292见附件的图片.... -
Lucene索引管理器(基于Luke修改而来)
2008-03-29 21:34 1830先看图来...... -
JBPM与SPRING事务整合之深度历险
2008-03-29 20:47 6573------------------此文很早就写了,不知何故在 ... -
实现MHT文件格式的解析和内容抽取
2008-03-29 01:56 10261由于我们的业务系统中有大量的MHT格式的资料,需要对其建立索引 ... -
超轻量的定时器
2007-12-26 20:41 1153项目中一个特殊要求,需要轻量的定时器程序,所以简单实现了一个: ... -
通过jsp标签封装的列表组件
2007-11-27 20:43 1551一套字表查询api,将字典表处理从业务代码(主要是sql关联) ... -
swing界面的屏幕取词
2007-11-27 20:25 2070针对let's swing blog上的方法进行了优化,完善了 ... -
基于Swing的JBPM设计器
2007-07-17 22:10 4292基于JBPM的流程设计器,屏蔽了JBPM的一些复杂功能,适合业 ...
相关推荐
经典manning 原板书。... It’s been a pleasure working with Don, but mostly it’s just nice to be able to pick his brain about the details of Struts 2. That alone is worth the price of admission.
very nice service nice haha
Nice Spinner NiceSpinner is a re-implementation of the default Android's spinner, with a nice arrow animation and a different way to display its content. It follows the material design guidelines, ...
Nice Vibrations v3.6
Nice Engage recording / Sentinel . Introduction to the NICE Engage Solution
Struts2 学习
仿nice标签
仿nice添加图片标签,用SQLite存储标签位置,下次重新加载
苏州默纳克NICE1000电梯专用变频器说明书
Android 仿照nice的刷新
非常nice的Spinner
NIST SP800-181 网络空间安全人才框架 NCWF,National Initiative for CybersecurityEducation (NICE)中文译本
集智达NICE-3100 VGA DRIVERrar,集智达NICE-3100 VGA DRIVER
杭电操作系统实验一修改nice值代码参考...............................................................................................
提供高性能的远程桌面和应用程序流.Windows驱动程序,允许没有GPU的EC2实例以更高的显示分辨率运行NICE DCV。
集智达-新汉NICE系列产品手册(中文)pdf,集智达-新汉NICE系列产品手册(中文)
NICE3000用户使用说明书3.3,莫纳克比较新的说明书 有最新的故障代码,相关参数也叙述比较全面
《NICE3000new电梯一体化控制器快速调试手册》.pdf
简单,智能和令人愉快的验证解决方案。 通过或最新版本或安装软件包 $ npm install nice-validator $ bower install nice-validator 入门 1.包括 2.包含nice-validator 宽度[removed]标签: < script src =" ...
Markdown 必备神器,Markdown 转公众号、知乎排版神器