- 浏览: 1524534 次
- 性别:
- 来自: 厦门
博客专栏
-
Spring 3.x企业实...
浏览量:463473
文章分类
最新评论
-
JyeChou:
学习Spring必学的Java基础知识(1)----反射 -
hhzhaoheng:
...
《Spring4.x企业应用开发实战》光盘资料下载 -
renlongnian:
//assertReflectionEquals(user1, ...
单元测试系列之3:测试整合之王Unitils -
骑着蜗牛超F1:
huang_yong 写道我的经验是,只需定义三层:1.ent ...
Spring的事务管理难点剖析(2):应用分层的迷惑 -
wangyudong:
工具地址貌似更新了哦https://github.com/Wi ...
几种常用的REST webservice客户端测试工具
此处省去废话100行:)
Unknow---- says:
你可以从spring的价值来考虑下..我对spring在项目的应用所带来的价值还是有怀疑..
Stamen says:
你选Acegi做权限 很适合 我的判断是一定可以胜任行业性的系统
Stamen says:
Spring我用得越深 发现他的实用性更好 你可以花时间多了解 再做判断。
Unknow---- says:
你说来看看,spring的价值
Stamen says:
Spring 2.0对配置做了大副的简化,而且你所说的契约模式 Spring是可以实现的
Stamen says:
我觉得主要有以下几点:
Unknow---- says:
还没写完哦..
Stamen says:
1)使类充分解耦,不需硬编码的方式 设计类和类之间的关系,它带来的好处是,你可以随时替换关联者,而无需动代码;
2)由于类都在Spring容器中统一管理,为加入切面编程提供了可能,业务对象从事务,安全性,日志等代码等非业务性的代码中脱离出来,业务类更简洁 只关注业务;
3)Spring使你更加方便地使用常用企业功能,如JavaMail,Timer,远程调用,缓存,安全等,Spring使得利用这些类库得到了很大的简化,而如果你直接用这些类库,学习曲线陡峭得很多;
Stamen says:
4)Spring使测试更加容易,对于Web的应用,它提供了很多Mock测试类,无需启动Web服务
Stamen says:
5)还有很多待发现的好处...
Unknow---- says:
第一点应该是spring的最核心的价值,也是最初的价值..但这点的实用价值在我们做项目中,真的有用吗?
Stamen says:
第一点 在一般项目中实用性并不明显
Unknow---- says:
第二点,切面所带来的思想远远比现在所带来的价值大..他的价值是什么.能带来多大的价值哦
Stamen says:
它更象是框架级的东西
Unknow---- says:
第三点是有价值了
Unknow---- says:
第四点易测试,,也是看项目如何做了..
Stamen says:
我觉得 第2点是工程性项目最有价值的地方,事务,安全,日志代码的拨离 太太提高了代码生产率
Unknow---- says:
事务,其实作用不大了..
Unknow---- says:
用配置的事务,可比用写代码的麻烦了..
Stamen says:
你看看Acegi就好了,它就是将程序的访问控制剥离出来 在业务代码中根据看不看访问控制的痕迹 ,这点太伟大了。
Stamen says:
“用配置的事务,可比用写代码的麻烦了..”只能说明你对Spring不够了解
Unknow---- says:
就是安全还可以有参考的价值..但我们做业务系统,很多是在界面控制权限的..而ACEGI是在服务端控制的..
Unknow---- says:
为什么这么说?
Unknow---- says:
你用配置的事务,比写代码的,有用的价值体现在哪
Stamen says:
Spring2.0提供了简洁的事务配置,利用AspectJ来做事务,配置的简化是数量级的,你可以看看这方面的资料
Unknow---- says:
能简洁到什么程度?
Stamen says:
首先,我觉得配置不是首要问题,首要问题是业务对象只需要关心业务逻辑才是关键中的关键
Unknow---- says:
这个从思想上没错,我一直认同这点..其实这点从根本上讲就是单一职责原则,无论是分层,还是把事务,安全,日志从业务中的抽取都是体现这点.
Stamen says:
业务对象只做自己手头上的工作,自己的工作究竟如何被组织起来完成一件“大事”业务对象不用去关心,这样业务对象的逻辑就大大简化了,我举一个例子,象69年的阿波罗登月项目 ,参加的单位,组织,学校有上千个,人有11万多,上面有一个总调度人总揽全局(Spring),而各个单位只负责自己手头的事,甚至某些单位只是简单按标准做好了螺丝钉。如果没有总揽大局的协调者,那么每个单位都需要双方去协调事务,那么项目的复杂度马上不能控制了。
Unknow---- says:
但我觉的更要从实用性考虑..就像EJB一样,它所体现的思想不错,但实用性太差了,所以被市场抛弃了
Stamen says:
EJB的复杂不在于声明事务,相反声明事务是EJB最大的亮点,EJB的复杂在于它和容器捆绑太死,以至于在开发中的测试上非常困难。
Stamen says:
测试的方便性直接影响到开发的效率,Spring比之EJB最大的提升就是易测试上,其次就是使POJO可以使用声明事务
Unknow---- says:
但它的思想是体现在组件思想上..这是它的核心思想,但EJB的实现很糟糕,所以开发人员使用时,实用价值太低了.所以被抛弃了..
Unknow---- says:
而SPRING的思想就是你提到的,问题是我们在项目中使用spring,真正能带来的实用价值是多大..这点才是最关键的..
Stamen says:
不管是组件也好 POJO也好 如果它易测试 易部署 对于实际的开发和应用 负面影响倒不会太大
Unknow---- says:
就像声明式事务,在我们以前所做的业务系统中,能比我们以前的方式带来多大价值,不是指思想上.而是指实用上..
Unknow---- says:
你所提到的易测试性,也很不错,这也是我以前所总结过的.
Stamen says:
价值就是简洁代码开发 提高项目进度 这难道还是不实实在在的价值吗
Unknow---- says:
spring在实现时,考虑到了易测试性,很好..所以作者真的是实战思想家
Stamen says:
你去拿一个模块,一个自己写事务管理 一个用Spring声明事务 比较两者的代码行 两者的开发效率 就一目了然了。
Unknow---- says:
简化代码,问题是简花了多少代码,其实我们在做业务系统中,事务很少为我们项目带来麻烦..很少BUG是由事务的问题带来的..而采用基于配置的事务,必须要运行时才能测试事务的完整性吧..
Stamen says:
叫程序员去一遍一遍写没有思想的事务管理代码本身就是一种人力资源甚至是智力资源的浪费。
Unknow---- says:
而且如果我们采用统一风格的事务,我们完全可以做到在一个地方写事务控制的代码,业务逻辑不需要涉及事务,可能更简单..
Stamen says:
一个地方写事务控制的代码???不太现实
Unknow---- says:
可以了..其实我们的业务系统很简单了.都是在action控制事务了..我们在commonaction中控制就可以了
Unknow---- says:
其实内可以考虑配置型事务真正实用的价值所在..
Stamen says:
哈哈 Action是展现层 展现层去干涉业务,你会被人踢的
Unknow---- says:
我的理解跟你不一样..事务不是简单的指数据库的事务哦.
Stamen says:
不管怎么样 事务都是业务层的负责 你把在扩展到展现层 是比较严重的设计缺陷
Stamen says:
假设Service还有一个C/S应用需要调用 ,或者一个WAP应用需要调用 Service层还能够通用吗
Unknow---- says:
举个例子吧.用户注册的,用户注册成功,必须要在数据库中插入用户记录和日志记录,还有在每天注册人数增加一,还要发送邮件,如果有一步出错,都要退回,这时候用配置的事务就很难解决了
Stamen says:
用Spring绝对可以解决你这个需求
Unknow---- says:
我觉的我们开发人员有一个毛病,就是想很多不存在的需求,所以导致设计偏向了.如果我们只把握最核心的需求,那我们的设计就很简单..所以我觉的设计简单,要比设计可扩展性更要考虑
Unknow---- says:
我注册失败后,还要让当天注册人数减一..用spring如何解决
Stamen says:
设计简单要事先满足一定的规范,象你让事务在Action中控制 这就有点过了
Unknow---- says:
其实你要看action它真正体现的是什么了,我觉的它是事务的发起者和结束者.所以在action中去简化它..就变的容易了..
Stamen says:
做一个ThrowableAdvice就可以了,当发现用户注册失败异常时,用户注册人数减一
Unknow---- says:
做切面时,你能调用HttpSession吗
Unknow---- says:
当天注册人数,我可能要操作用户的session,如何在你的ThrowableAdvice做呢
Stamen says:
Action是业务服务的调用者,但不是事务控制的管理者 事务是业务的范畴
Unknow---- says:
如果做一个平台,我会采用基于配置的事务,如果我像平时做业务系统,当然要怎么做最简单就怎么做了.
Stamen says:
让ThrowableAdvice实现ApplicationContextAware 就可以获取Session了。
Unknow---- says:
这只是个例子.我觉的spring的思想不错,但很多东西都是刚开始,还没完善,所以如果现在用这些特性,可能把本来很简单的项目弄的很复杂..这是我们做业务系统必须要考虑的..你可以想想用spring做我们以前的业务系统,能不能带来你所说的价值..
Stamen says:
不会错,简单的业务系统怎么做都可以 你甚至可以只用JSP实现所有功能,关键是为什么大师们都坚持Service和View层要解耦 他们的经验和理解力 已经实践经验都是在我们之上很多倍的
Unknow---- says:
还有一点你要考虑的,国内的IT环境跟国外的不一样.我觉的这点就带来很大的影响了
Unknow---- says:
你可以考虑下我们以前的业务系统和采用spring后,你可以对比下..
Stamen says:
一个东西要用好它就先要搞透它 否则不但得不到简化 可以带来更多坏的影响,就象F22性能虽好 但开不来还如拿大刀
Unknow---- says:
很多开发人员都是国外人员提什么技术,国外人员说好,国内的就跟风,我觉的很多开发人员缺乏对技术的鉴证性,就是这个新技术能不能为项目带来生产率和质量的提高,这是最关键的.鉴证性如何考虑呢?有一点很重要,就是实用性,在项目中去实践..
Stamen says:
对,国内的开发人员半调儿的太多 稍微培训一下就上路 在学校学的也都是过时的东西 因为没有自己的思想 跟风就比较严重,所以才会有EJB热
Unknow---- says:
是啊..所以如果一个技术没转眼透,对技术的理解不透彻,都可以对使用这个技术带来错误的判断.也许我犯了这个错误,但至少我还没看到那个人能真正说出在他们的项目中,用spring带来了生产率和质量的提高..
Stamen says:
不对 Spring已经为项目带来了生产率的提高 这是用过Spring的开发人员的普遍感受 Spring是从劳动中来到劳动中去的框架 而非EJB这种皇家血统的
Unknow---- says:
是啊.你说的没错,那是国外..国内呢..你要看你周围的.而不是从网络上别人这么说哦
Unknow---- says:
像EJB刚兴起的时候也是这么说的哦
Stamen says:
我自己就觉得Spring让我编码轻松了不少 以前写事务代码真是太单调了
Unknow---- says:
国内很多人说用SPRING为项目带来了生产率的提高,但很多都是假冒了,没有真正去思考,是不是真的带来了,这点在网上特别普遍..
Stamen says:
用Spring做开发的项目是非常多的 Xxx公司这边都用Spring,我原来在yyy公司做的几个项目也是用Spring
Unknow---- says:
写代码单调,这不是理由哦. 是要类比以前写的,是不是真的比以前写代码写的更快了..你想想以前写新增用户的事务逻辑,也就两行代码,短短的两句..而用spring呢.你要配置两行吧.
Stamen says:
事务代码都不用考虑了 10分事去了2分 怎么不省事
Unknow---- says:
但我问了那些yyy公司的人.有咨询过他们,他们说不错,但我问到真正的点子上的时候,却上来.都觉的跟以前比,其实真正没有带来多大的价值了
Unknow---- says:
但你要配置哦..你在代码中不写,但在配置文件中要配置哦.
Unknow---- says:
像小翁,张崇镇,都是在yyy公司最早使用的,也是使用的最多的..我都问过他们..
Stamen says:
就象某个人 由于前列腺 一天上班要上厕所20次 现成前列腺好了 晚上回来上一次就行 难道还能不轻松吗
Unknow---- says:
但我在业务系统也可以做到只写一处就可以了..很简单.连配置文件都不用配置,如果出错了,我只看那处代码就行了..错误信息打印的都很清楚,而用配置呢,追踪BUG可能不如原始方式好吧..而且可能配置写错了,如果不太理解框架的话,还可能因为配置错了,让你找半天的BUG,这都是基于配置的缺陷.
Stamen says:
那就是看配置的量和代码的量哪个大,事务要获取资源 ,做事务提供 回滚 释放资源 代码加起来没有20行恐怕搞不定,但配置有多少行,用一个parent事务<bean> 事务<bean>继承的方式配置,你只要为一个方法声明事务的属性就可以了,顶多1行
Stamen says:
我刚才说过 你的设计是不合理的
Stamen says:
是为了达到目标不择手段的那种
Unknow---- says:
代码量不大了.业务系统已经简化事务代码了...不像你说的,还要回滚处理,那太原始了.
Stamen says:
你不要去问别人 自己做一个试试就OK了 当然刚开始会觉得比较麻烦 用多了就不会了 毕竟学一个东西是要代价的
Unknow---- says:
这可能是我的设计理念导致的..就是设计一定要简单..如果我用这种方式,就可以做好业务系统,而且这种方式在我做过的业务系统中都很适用,为什么不采用呢,难道还要考虑像国外那么复杂的IT环境,或者考虑我的业务系统可能慢慢变成像电信银行这么大的系统吗? 我觉的这种是过度考虑需求.
Stamen says:
之所以觉得不太好 我觉得很大部分原因是认识不够 还有就是固定思维
Stamen says:
那我问你 如果展现不是一种方式 用C/S 有WAP,你Service能通过吗,是不是事务代码都要重写,不是多种展现 ,你哪天觉得Struts到尽头了,换个
Stamen says:
Webwork ,方便吗?
Unknow---- says:
webwork是一样的..
Stamen says:
如果设计不能提供这种起码的灵活性 还有设计干什么
Unknow---- says:
我觉的你考虑的过度了..很多开发人员有个问题,就是过分考虑需求..
Unknow---- says:
设计都是有上下文的.. 你觉的做业务系统,设计最主要考虑的角度是什么? 不是灵活性或者可扩展性吧..
Stamen says:
好 ,先假不存在多展现和切换展现端技术的问题,你这样设计 能够允许分层开发吗?
Unknow---- says:
不要片面的追求完美的设计,我觉的做业务系统最主要考虑的就是功能性和简单行.
Unknow---- says:
可以允许分层开发啊.这不会为分层开发带来任何问题啊..
Stamen says:
你说的这些也是要保证 ,但凡事有度
Stamen says:
事务的逻辑是业务上还是展现上的?
Unknow---- says:
问题我们做的架构,可以让开发人员不需要考虑事务了啊..因为底层已经都实现这种服务了
Stamen says:
你的事务都是一个Action方法一个事务吗?
Unknow---- says:
假如就在commonAction中实现了.开发人员继承一个action就可以获得事务服务了
Unknow---- says:
是啊..
Stamen says:
不跟你玩了
Stamen says:
一个Action方法一个事务,你这个大头
Stamen is searching for:
我要找我笑掉的大牙了
MSN Search says:
We couldn't find any sites containing "我要找我笑掉的大牙了 ". Try using different search words.
Unknow---- says:
呵..这就是我的架构设计思路..你可以考虑下..想想我为什么这么做..而不是一定要做到思想的完美无缺性..我觉的我实践的体会就是设计一定不要考虑做到设计的完美性.
Stamen says:
你也走极端了
Unknow---- says:
哈....这都是来源于实践中的设计.而不是凭空捏造的.当然都有来源了..
Stamen says:
那只能说我们见过的项目多太简单了
Unknow---- says:
也许吧..因为我把设计的简单化看的太重了,就是我的设计一定要保证生产率和质量的提高,我的最高设计原则就是这个.其他的不考虑.
Stamen says:
我现在的项目就不允许这种粗细度
Unknow---- says:
对哦..所以我就跟你说我们的环境跟国外的IT环境不一样哦..
Unknow---- says:
那一天有空,你可以把你的项目说给我听听..也许我会改变我的想法.
Stamen says:
我说个我现在项目的一个现实需求吧
Unknow---- says:
可以啊
Stamen says:
用户升级产品事务失败,将信息记录下来,并发Mail给管理员,
这里有三个业务,升级产品事务 记录场景数据事务 发Mail业务 但都通过一个Action方法处理
Unknow---- says:
如果记录场景数据失败,或者发email失败呢..
Stamen says:
框架的简单是在能够满足业务的需求的灵活性上来做,它有一个基础 ,而不是不择手段的简化 ,否则就象60年代的大炼钢铁 有产量没有质量了。
Unknow---- says:
但你要考虑国内的软件背景,一个业务系统软件究竟能用多久..不同的上下文,就有不同的设计..
Stamen says:
productSerivce.upgrade(product);
Stamen says:
try{
productSerivce.upgrade(product);
}catch( RuntimeException e)
{
productService.recordFailLog( product);
mailSender.send( mail);
}
Unknow---- says:
而且不是没有质量,我设计的最高原则就是软件生产率和质量的提高..
Unknow---- says:
然后呢
Stamen says:
你上面提的小小需求你的框架都满足不了了 还说质量和生产率 质量和生产率是要做对事的前提下
Unknow---- says:
错了哦..设计是依赖上下文的,老大..如果需求是这样的,当然设计要去改变了,难道一套设计就能走天下嘛....
Stamen says:
你的设计是要通用的,又不是只给一个项目用
Stamen says:
给一个项目用 就直接写JSP 也是可以的
Unknow---- says:
那你也极端了哦.. 这种我的架构也是可以做的..
Unknow---- says:
spring如何实现呢
Stamen says:
别的先不说,有两个解决思想是一定有问题的:
1)事务在Action层控制
2)事务粒度为一个请求
Unknow---- says:
那你说说问题的所在吧
Stamen says:
上面不都说了 笨
Unknow---- says:
没有吧..我怎么没发现啊..
Stamen says:
笨 笨 笨
Unknow---- says:
问题还是你怎么看待action了..
Unknow---- says:
那你用spring怎么解决
Stamen says:
Action负责两部分的功能 :
1) 页面流程控制 ,如失败转向哪儿 失败转向哪儿 等;
2) 业务流程控制 ,如上面我举的那个例子,成功升级后 如果处理 升级失败后 如果处理等
Unknow---- says:
你说的没错了..你的那些代码应该叫做应用组织逻辑..
Unknow---- says:
它不属于核心的业务逻辑..如果你把action来作为应用逻辑组成层的话.也是可以做到的
Stamen says:
Action并不是完全不负责业务 ,但它控制的业务逻辑是粗粒度的 是业务流程层面上的,而非事务流程层面
Unknow---- says:
当然了..spring的基于配置事务是很用的,我在青鸟中所教的架构,就是用spring的事务,当时也提到一个spring唯一能看到实用性的价值
Stamen says:
不说其实的,这一点已经很不错了
Stamen says:
其他
Stamen says:
你去给你们领导吹吹风吧,我到时给你们培训Spring
Unknow---- says:
呵..就像我说的上下文一样,如果上下文不一样,设计真的不一样,就像你提的,我在北大青鸟就是用spring解决的.但不用spring也是可以解决的.
Unknow---- says:
可以啊..没问题啊..不过要讲实用的..
Stamen says:
嗯 也是有一定的道理 ,不过我不相信电力的业务会那么简单
Unknow---- says:
不过讲下设计思想更好了
Unknow---- says:
电力业务没你想的复杂了.可能更简单..
Stamen says:
Xxx公司的开发人员水平还不太高 目前更突出的问题是开发实现上 设计思想和你聊就OK了
Stamen says:
如果事务是请求级别的 那就OK
Stamen says:
不过没有1K 不去讲哦
Unknow---- says:
是啊..但我是希望两个都有了,多讲下思想,对他们改变思想比较好..希望他们能听到好的思想,可以在项目中去体会..
Unknow---- says:
我帮你提下..
Unknow---- says:
不过不知道行不行哦.因为我以前就提过,但没成功..
Stamen says:
不要紧 可以随便说 我不一定有空
Stamen says:
想半年呆在家里 一边搞好生产 一边搞建设
AspectJ的使用要比Spring的配置简洁得多。使用Spring的AOP并不会不知不觉,原理是相同的。
还有你说的整合问题,Web没用过,没有发言权。同持久层的整合是鸡肋,有时还不得不直接访问。
简化异常处理是啥意思?单元测试还需要启动Spring麽?
这里说的单元测试,严格讲应该叫“集成单元测试”了,确实会启动Spring容器,参见江南白衣的幼学琼林--Spring下的单元测试要点
Spring对web层框架的整合:struts/ww/jsf可以随意切换,Equinox(同名,但不是那个Eclipse的项目)项目充分展示了这种能力,还有整合hibernate/iBATIS
简化异常处理:Spring提供了一种设计巧妙的异常处理机制,可以把底层抛的异常转换成runtime型的,使得应用代码及其简单,最明显的例子就是,虽然我在用着Hibernate,但我的DAO里根本没有Hibernate的异常,甚至没有import任何Hibernate的类;
现在人都很懒惰,程序员尤其懒惰而且据称是种美德,Spring提供了一站式解决方案而且解决的还挺优雅,所以能流行,那个AspectJ虽然某方面很厉害,但是他解决的问题太单一了,我这样的懒人一般不愿意投入精力去学
而且AspectJ不是已经合并到Spring2.0了吗,咱们还在这里争什么呢?
hehe
Rod Johnson自己在《J2ee 设计开发编程指南》里都是主张 问题驱动而不是技术驱动。
Spring的框架,应该说是针对某一类问题提供了一套解决方法。但是,同样的问题并非不能用其他方法解决。
应该说,使用spring,可以减少一些自己设计编写工具并且整合的工作量。
如果有一群同样技术水平,配合很默契的工程师,使用不使用spring,其实差别不大。
spring就像外面卖的工具包,螺丝刀钳子之类的都有。家用维修基本够了。一般人拿过来就能用。
但是,对一些专门工业的人来说,比如修汽车,他们用的工具从尺寸上,精细度上可能就不一样。有时候用惯了自己手里的工具,拿个大众化的工具,即使能干同样的事情,也觉得不习惯。甚至有人更喜欢自己定制工具,更顺手,更省力(对他个人,但不一定适合别人)。
AspectJ的使用要比Spring的配置简洁得多。使用Spring的AOP并不会不知不觉,原理是相同的。
还有你说的整合问题,Web没用过,没有发言权。同持久层的整合是鸡肋,有时还不得不直接访问。
简化异常处理是啥意思?单元测试还需要启动Spring麽?
来搅一下浑水。
支持wobuzhi。
关于spring俺们就用了个Remoting,大部分使用AspectJ就更好的解决IOC的问题,只有很少几个使用了Spring的IOC,实际上也是可以通过Aspect搞定的,能够用就没管。
那你如何管理Hibernate的SessionFactory获取,Session的打开和关闭,事务的控制呢?说说看吧
用一个Aspect截获service的方法就可以做到。
我是初学者,弱弱地请教一下:Spring 和 JBOSS Seam 有可比性吗?Spring自身或者里面的集成的开源框架中,哪个部分对应Seam集成的jBPM?
谢谢!
spring本身就可以很好的和jBPM集成。
Spring是不错, 不过它的流行占了EJB的便宜. Rod大哥如果没有打出j2ee without ejb的旗号首先不会吸引那么多人的注意. Spring的流行很大程度归功于Rod的两本书以及其他一些宣传方式. 我不否认spring带来的很多benefit, 但spring的缺点也不少. 所以一味鼓吹一种框架没啥意思, 自己用就行了, 没有必要到处宣传要别人也使用. 好不好, 由别人自己决定. 今后主流的开发java应用的架构,应该有两种, 一种是基于J2ee标准的架构就是jsf+ejb3, 还有一种就是spring加上一些其他开源框架. Spring这一边现在占据了优势, 如果说是技术上的优势, 不如说是抢了个j2ee规范没有出来的空挡的先发优势. 随着jsf, ejb3的成熟, 会有越来越多的人转向这个架构. 不过不会有哪方获取完全的胜利.
我是初学者,弱弱地请教一下:Spring 和 JBOSS Seam 有可比性吗?Spring自身或者里面的集成的开源框架中,哪个部分对应Seam集成的jBPM?
谢谢!我不太了解Jboss 的Seam. 但是Jbpm是做工作流的, 工作流产品很重要的一点是要有GUI的可以拖拉的工具来支持工作流的开发, spring似乎没有这样的特性. 不过spring可以集成一些开源的工作流引擎, 有的也带了一些GUI的工具, 比如说OSWORKFLOW, 不过还是比较弱. 从JBOSS的整个产品线的角度看, JBPM是SOA方面的产品, 与其说是一个开发框架, 它其实是一个产品化的东西. 使用的时候更多的是配置而非编程.不过这个产品和IBM,ORACLE的产品相比还是功能简单了点, 缺乏竞争力, 主要优势可能就是免费的.
Spring是不错, 不过它的流行占了EJB的便宜. Rod大哥如果没有打出j2ee without ejb的旗号首先不会吸引那么多人的注意. Spring的流行很大程度归功于Rod的两本书以及其他一些宣传方式. 我不否认spring带来的很多benefit, 但spring的缺点也不少. 所以一味鼓吹一种框架没啥意思, 自己用就行了, 没有必要到处宣传要别人也使用. 好不好, 由别人自己决定. 今后主流的开发java应用的架构,应该有两种, 一种是基于J2ee标准的架构就是jsf+ejb3, 还有一种就是spring加上一些其他开源框架. Spring这一边现在占据了优势, 如果说是技术上的优势, 不如说是抢了个j2ee规范没有出来的空挡的先发优势. 随着jsf, ejb3的成熟, 会有越来越多的人转向这个架构. 不过不会有哪方获取完全的胜利.
我是初学者,弱弱地请教一下:Spring 和 JBOSS Seam 有可比性吗?Spring自身或者里面的集成的开源框架中,哪个部分对应Seam集成的jBPM?
谢谢!
Spring是不错, 不过它的流行占了EJB的便宜. Rod大哥如果没有打出j2ee without ejb的旗号首先不会吸引那么多人的注意. Spring的流行很大程度归功于Rod的两本书以及其他一些宣传方式. 我不否认spring带来的很多benefit, 但spring的缺点也不少. 所以一味鼓吹一种框架没啥意思, 自己用就行了, 没有必要到处宣传要别人也使用. 好不好, 由别人自己决定. 今后主流的开发java应用的架构,应该有两种, 一种是基于J2ee标准的架构就是jsf+ejb3, 还有一种就是spring加上一些其他开源框架. Spring这一边现在占据了优势, 如果说是技术上的优势, 不如说是抢了个j2ee规范没有出来的空挡的先发优势. 随着jsf, ejb3的成熟, 会有越来越多的人转向这个架构. 不过不会有哪方获取完全的胜利.
完全同意,Spring是在大家对EJB无限迷茫,不知所措后,适时出现的一缕清新的阳光,才使大家在短时间内从之如流。
Spring是不错, 不过它的流行占了EJB的便宜. Rod大哥如果没有打出j2ee without ejb的旗号首先不会吸引那么多人的注意. Spring的流行很大程度归功于Rod的两本书以及其他一些宣传方式. 我不否认spring带来的很多benefit, 但spring的缺点也不少. 所以一味鼓吹一种框架没啥意思, 自己用就行了, 没有必要到处宣传要别人也使用. 好不好, 由别人自己决定. 今后主流的开发java应用的架构,应该有两种, 一种是基于J2ee标准的架构就是jsf+ejb3, 还有一种就是spring加上一些其他开源框架. Spring这一边现在占据了优势, 如果说是技术上的优势, 不如说是抢了个j2ee规范没有出来的空挡的先发优势. 随着jsf, ejb3的成熟, 会有越来越多的人转向这个架构. 不过不会有哪方获取完全的胜利.
还有构造函数注射。知道为什么很多人反感pico么?一个原因是它自己觉得自己了不起,喋喋不休地说构造器注射比setter注射好,spring好就好在不做这种价值观的判断,setter/ctor都支持,你爱用哪个用哪个。
所以什么推荐使用的话没什么意义。很多时候应该是具体应用决定工具,而不是反过来。我需要用构造器,因为系统本来就是用构造汉书设计的。不能因为你spring推荐就改我的设计,这就叫侵入性了。
为什么我不自己实现这个功能呢?
1。比较麻烦
2。ctor autowiring是spring已经实现的功能。要求我重复实现一遍而不是重用已经做好的,好像不太合理。就是spring如果实现这个功能的时候不是重用原有的代码,而是重新再写一遍,也是bad smell。
当然,yan是可以处理这种需求的。这个功能在我们重构遗留系统的时候也发现还是有实际价值的。
说到心坎上了!!
说得太对了!!!
何谓很多基本的spring和acegi的概念?spring,acegi只是为你做了N多的事情,留给你的只是一定量的配置,若干的代码量而已。有什么新东西吗?甚至可以说和ajax的产生没什么区别,唯一的好处就是其体现出来的设计思想,可有一些也是借鉴而已。
不是所有的项目都“体大如牛”的,从实用角度考虑,什么方便用什么,现在可用的东西那么多,需要什么我拿来用就是了,只要能简单,正确地表达出我某一个交易要做什么,不能做什么,与其他交易或其他系统中的业务是否发生关联,如何通讯就可以了。
重构只是一个美好的愿望,全中国有那么多的业务系统,大多数都是一个版本一个版本迭代出来的产物,你觉得上一个版本有bad smell,代码冗余,耦合极强,难道你就去重新构造这个业务系统?等你重新构造后,它的市场价值也没了,投产还有何意义?你所做的一切还有何意义?所以我觉得重构对提高个人代码素养有很大的好处,对实际的业务系统意义不大。
再来说说XP,所谓的“结对编程”,国外不晓得乍应用的,对于国内,乍应用,一个开发,一个辅助,两人轮换,可对于开发,每人都有自己的一套小九九,对于不同的需求,每人都有不同的理解,估计要两人能达到一致,恐怕就得耗费一段时间了,在开发过程中也难免不会出现意见的分歧,这样情况如何解决?老外是怎样解决的?也许你会说,每人做一个交易,一个流程,这样就不“打架”了,貌似可行,可前提是这两人得“对眼”,要么能力接近,要么关系不错,否则如何解决两人的合作关系?除非是一男一女合作。。。。。。
随便说说,欢迎讨论。。。。。另外回贴的时候,不知为何cpu占用过高,风扇时不时地在转,我用的maxthon,没开其它东西,噢,对了,开空调来的:)怀疑是文本编辑器有资源占用问题,呵呵。
太多的误解了。
关于简单:你似乎认为多用一种框架就多一些复杂性,所以你做简单的东西就没必要用,体现实用主义。
其实spring一个最大的优点就是简单,可以大大减少代码量
关于重构:从你举的例子可以看出你完全不知道什么是重构,你说的那个是重写。
关于结对编程:你说“每人都有不同的理解,估计要两人能达到一致,恐怕就得耗费一段时间了”
难道这个时间浪费了吗,这不正是明确需求的过程吗,难道每个人在需求不明、缺少讨论的情 况下开始工作不是最大的浪费吗?
最后:你似乎也不理解Spring对可测试性带来的巨大好处,以及可测试性本身的重要性。
还是对Spring深入了解了以后再下论断吧,不要老是随便说说,这是态度问题!
Unknow---- says:
你可以从spring的价值来考虑下..我对spring在项目的应用所带来的价值还是有怀疑..
Stamen says:
你选Acegi做权限 很适合 我的判断是一定可以胜任行业性的系统
Stamen says:
Spring我用得越深 发现他的实用性更好 你可以花时间多了解 再做判断。
Unknow---- says:
你说来看看,spring的价值
Stamen says:
Spring 2.0对配置做了大副的简化,而且你所说的契约模式 Spring是可以实现的
Stamen says:
我觉得主要有以下几点:
Unknow---- says:
还没写完哦..
Stamen says:
1)使类充分解耦,不需硬编码的方式 设计类和类之间的关系,它带来的好处是,你可以随时替换关联者,而无需动代码;
2)由于类都在Spring容器中统一管理,为加入切面编程提供了可能,业务对象从事务,安全性,日志等代码等非业务性的代码中脱离出来,业务类更简洁 只关注业务;
3)Spring使你更加方便地使用常用企业功能,如JavaMail,Timer,远程调用,缓存,安全等,Spring使得利用这些类库得到了很大的简化,而如果你直接用这些类库,学习曲线陡峭得很多;
Stamen says:
4)Spring使测试更加容易,对于Web的应用,它提供了很多Mock测试类,无需启动Web服务
Stamen says:
5)还有很多待发现的好处...
Unknow---- says:
第一点应该是spring的最核心的价值,也是最初的价值..但这点的实用价值在我们做项目中,真的有用吗?
Stamen says:
第一点 在一般项目中实用性并不明显
Unknow---- says:
第二点,切面所带来的思想远远比现在所带来的价值大..他的价值是什么.能带来多大的价值哦
Stamen says:
它更象是框架级的东西
Unknow---- says:
第三点是有价值了
Unknow---- says:
第四点易测试,,也是看项目如何做了..
Stamen says:
我觉得 第2点是工程性项目最有价值的地方,事务,安全,日志代码的拨离 太太提高了代码生产率
Unknow---- says:
事务,其实作用不大了..
Unknow---- says:
用配置的事务,可比用写代码的麻烦了..
Stamen says:
你看看Acegi就好了,它就是将程序的访问控制剥离出来 在业务代码中根据看不看访问控制的痕迹 ,这点太伟大了。
Stamen says:
“用配置的事务,可比用写代码的麻烦了..”只能说明你对Spring不够了解
Unknow---- says:
就是安全还可以有参考的价值..但我们做业务系统,很多是在界面控制权限的..而ACEGI是在服务端控制的..
Unknow---- says:
为什么这么说?
Unknow---- says:
你用配置的事务,比写代码的,有用的价值体现在哪
Stamen says:
Spring2.0提供了简洁的事务配置,利用AspectJ来做事务,配置的简化是数量级的,你可以看看这方面的资料
Unknow---- says:
能简洁到什么程度?
Stamen says:
首先,我觉得配置不是首要问题,首要问题是业务对象只需要关心业务逻辑才是关键中的关键
Unknow---- says:
这个从思想上没错,我一直认同这点..其实这点从根本上讲就是单一职责原则,无论是分层,还是把事务,安全,日志从业务中的抽取都是体现这点.
Stamen says:
业务对象只做自己手头上的工作,自己的工作究竟如何被组织起来完成一件“大事”业务对象不用去关心,这样业务对象的逻辑就大大简化了,我举一个例子,象69年的阿波罗登月项目 ,参加的单位,组织,学校有上千个,人有11万多,上面有一个总调度人总揽全局(Spring),而各个单位只负责自己手头的事,甚至某些单位只是简单按标准做好了螺丝钉。如果没有总揽大局的协调者,那么每个单位都需要双方去协调事务,那么项目的复杂度马上不能控制了。
Unknow---- says:
但我觉的更要从实用性考虑..就像EJB一样,它所体现的思想不错,但实用性太差了,所以被市场抛弃了
Stamen says:
EJB的复杂不在于声明事务,相反声明事务是EJB最大的亮点,EJB的复杂在于它和容器捆绑太死,以至于在开发中的测试上非常困难。
Stamen says:
测试的方便性直接影响到开发的效率,Spring比之EJB最大的提升就是易测试上,其次就是使POJO可以使用声明事务
Unknow---- says:
但它的思想是体现在组件思想上..这是它的核心思想,但EJB的实现很糟糕,所以开发人员使用时,实用价值太低了.所以被抛弃了..
Unknow---- says:
而SPRING的思想就是你提到的,问题是我们在项目中使用spring,真正能带来的实用价值是多大..这点才是最关键的..
Stamen says:
不管是组件也好 POJO也好 如果它易测试 易部署 对于实际的开发和应用 负面影响倒不会太大
Unknow---- says:
就像声明式事务,在我们以前所做的业务系统中,能比我们以前的方式带来多大价值,不是指思想上.而是指实用上..
Unknow---- says:
你所提到的易测试性,也很不错,这也是我以前所总结过的.
Stamen says:
价值就是简洁代码开发 提高项目进度 这难道还是不实实在在的价值吗
Unknow---- says:
spring在实现时,考虑到了易测试性,很好..所以作者真的是实战思想家
Stamen says:
你去拿一个模块,一个自己写事务管理 一个用Spring声明事务 比较两者的代码行 两者的开发效率 就一目了然了。
Unknow---- says:
简化代码,问题是简花了多少代码,其实我们在做业务系统中,事务很少为我们项目带来麻烦..很少BUG是由事务的问题带来的..而采用基于配置的事务,必须要运行时才能测试事务的完整性吧..
Stamen says:
叫程序员去一遍一遍写没有思想的事务管理代码本身就是一种人力资源甚至是智力资源的浪费。
Unknow---- says:
而且如果我们采用统一风格的事务,我们完全可以做到在一个地方写事务控制的代码,业务逻辑不需要涉及事务,可能更简单..
Stamen says:
一个地方写事务控制的代码???不太现实
Unknow---- says:
可以了..其实我们的业务系统很简单了.都是在action控制事务了..我们在commonaction中控制就可以了
Unknow---- says:
其实内可以考虑配置型事务真正实用的价值所在..
Stamen says:
哈哈 Action是展现层 展现层去干涉业务,你会被人踢的
Unknow---- says:
我的理解跟你不一样..事务不是简单的指数据库的事务哦.
Stamen says:
不管怎么样 事务都是业务层的负责 你把在扩展到展现层 是比较严重的设计缺陷
Stamen says:
假设Service还有一个C/S应用需要调用 ,或者一个WAP应用需要调用 Service层还能够通用吗
Unknow---- says:
举个例子吧.用户注册的,用户注册成功,必须要在数据库中插入用户记录和日志记录,还有在每天注册人数增加一,还要发送邮件,如果有一步出错,都要退回,这时候用配置的事务就很难解决了
Stamen says:
用Spring绝对可以解决你这个需求
Unknow---- says:
我觉的我们开发人员有一个毛病,就是想很多不存在的需求,所以导致设计偏向了.如果我们只把握最核心的需求,那我们的设计就很简单..所以我觉的设计简单,要比设计可扩展性更要考虑
Unknow---- says:
我注册失败后,还要让当天注册人数减一..用spring如何解决
Stamen says:
设计简单要事先满足一定的规范,象你让事务在Action中控制 这就有点过了
Unknow---- says:
其实你要看action它真正体现的是什么了,我觉的它是事务的发起者和结束者.所以在action中去简化它..就变的容易了..
Stamen says:
做一个ThrowableAdvice就可以了,当发现用户注册失败异常时,用户注册人数减一
Unknow---- says:
做切面时,你能调用HttpSession吗
Unknow---- says:
当天注册人数,我可能要操作用户的session,如何在你的ThrowableAdvice做呢
Stamen says:
Action是业务服务的调用者,但不是事务控制的管理者 事务是业务的范畴
Unknow---- says:
如果做一个平台,我会采用基于配置的事务,如果我像平时做业务系统,当然要怎么做最简单就怎么做了.
Stamen says:
让ThrowableAdvice实现ApplicationContextAware 就可以获取Session了。
Unknow---- says:
这只是个例子.我觉的spring的思想不错,但很多东西都是刚开始,还没完善,所以如果现在用这些特性,可能把本来很简单的项目弄的很复杂..这是我们做业务系统必须要考虑的..你可以想想用spring做我们以前的业务系统,能不能带来你所说的价值..
Stamen says:
不会错,简单的业务系统怎么做都可以 你甚至可以只用JSP实现所有功能,关键是为什么大师们都坚持Service和View层要解耦 他们的经验和理解力 已经实践经验都是在我们之上很多倍的
Unknow---- says:
还有一点你要考虑的,国内的IT环境跟国外的不一样.我觉的这点就带来很大的影响了
Unknow---- says:
你可以考虑下我们以前的业务系统和采用spring后,你可以对比下..
Stamen says:
一个东西要用好它就先要搞透它 否则不但得不到简化 可以带来更多坏的影响,就象F22性能虽好 但开不来还如拿大刀
Unknow---- says:
很多开发人员都是国外人员提什么技术,国外人员说好,国内的就跟风,我觉的很多开发人员缺乏对技术的鉴证性,就是这个新技术能不能为项目带来生产率和质量的提高,这是最关键的.鉴证性如何考虑呢?有一点很重要,就是实用性,在项目中去实践..
Stamen says:
对,国内的开发人员半调儿的太多 稍微培训一下就上路 在学校学的也都是过时的东西 因为没有自己的思想 跟风就比较严重,所以才会有EJB热
Unknow---- says:
是啊..所以如果一个技术没转眼透,对技术的理解不透彻,都可以对使用这个技术带来错误的判断.也许我犯了这个错误,但至少我还没看到那个人能真正说出在他们的项目中,用spring带来了生产率和质量的提高..
Stamen says:
不对 Spring已经为项目带来了生产率的提高 这是用过Spring的开发人员的普遍感受 Spring是从劳动中来到劳动中去的框架 而非EJB这种皇家血统的
Unknow---- says:
是啊.你说的没错,那是国外..国内呢..你要看你周围的.而不是从网络上别人这么说哦
Unknow---- says:
像EJB刚兴起的时候也是这么说的哦
Stamen says:
我自己就觉得Spring让我编码轻松了不少 以前写事务代码真是太单调了
Unknow---- says:
国内很多人说用SPRING为项目带来了生产率的提高,但很多都是假冒了,没有真正去思考,是不是真的带来了,这点在网上特别普遍..
Stamen says:
用Spring做开发的项目是非常多的 Xxx公司这边都用Spring,我原来在yyy公司做的几个项目也是用Spring
Unknow---- says:
写代码单调,这不是理由哦. 是要类比以前写的,是不是真的比以前写代码写的更快了..你想想以前写新增用户的事务逻辑,也就两行代码,短短的两句..而用spring呢.你要配置两行吧.
Stamen says:
事务代码都不用考虑了 10分事去了2分 怎么不省事
Unknow---- says:
但我问了那些yyy公司的人.有咨询过他们,他们说不错,但我问到真正的点子上的时候,却上来.都觉的跟以前比,其实真正没有带来多大的价值了
Unknow---- says:
但你要配置哦..你在代码中不写,但在配置文件中要配置哦.
Unknow---- says:
像小翁,张崇镇,都是在yyy公司最早使用的,也是使用的最多的..我都问过他们..
Stamen says:
就象某个人 由于前列腺 一天上班要上厕所20次 现成前列腺好了 晚上回来上一次就行 难道还能不轻松吗
Unknow---- says:
但我在业务系统也可以做到只写一处就可以了..很简单.连配置文件都不用配置,如果出错了,我只看那处代码就行了..错误信息打印的都很清楚,而用配置呢,追踪BUG可能不如原始方式好吧..而且可能配置写错了,如果不太理解框架的话,还可能因为配置错了,让你找半天的BUG,这都是基于配置的缺陷.
Stamen says:
那就是看配置的量和代码的量哪个大,事务要获取资源 ,做事务提供 回滚 释放资源 代码加起来没有20行恐怕搞不定,但配置有多少行,用一个parent事务<bean> 事务<bean>继承的方式配置,你只要为一个方法声明事务的属性就可以了,顶多1行
Stamen says:
我刚才说过 你的设计是不合理的
Stamen says:
是为了达到目标不择手段的那种
Unknow---- says:
代码量不大了.业务系统已经简化事务代码了...不像你说的,还要回滚处理,那太原始了.
Stamen says:
你不要去问别人 自己做一个试试就OK了 当然刚开始会觉得比较麻烦 用多了就不会了 毕竟学一个东西是要代价的
Unknow---- says:
这可能是我的设计理念导致的..就是设计一定要简单..如果我用这种方式,就可以做好业务系统,而且这种方式在我做过的业务系统中都很适用,为什么不采用呢,难道还要考虑像国外那么复杂的IT环境,或者考虑我的业务系统可能慢慢变成像电信银行这么大的系统吗? 我觉的这种是过度考虑需求.
Stamen says:
之所以觉得不太好 我觉得很大部分原因是认识不够 还有就是固定思维
Stamen says:
那我问你 如果展现不是一种方式 用C/S 有WAP,你Service能通过吗,是不是事务代码都要重写,不是多种展现 ,你哪天觉得Struts到尽头了,换个
Stamen says:
Webwork ,方便吗?
Unknow---- says:
webwork是一样的..
Stamen says:
如果设计不能提供这种起码的灵活性 还有设计干什么
Unknow---- says:
我觉的你考虑的过度了..很多开发人员有个问题,就是过分考虑需求..
Unknow---- says:
设计都是有上下文的.. 你觉的做业务系统,设计最主要考虑的角度是什么? 不是灵活性或者可扩展性吧..
Stamen says:
好 ,先假不存在多展现和切换展现端技术的问题,你这样设计 能够允许分层开发吗?
Unknow---- says:
不要片面的追求完美的设计,我觉的做业务系统最主要考虑的就是功能性和简单行.
Unknow---- says:
可以允许分层开发啊.这不会为分层开发带来任何问题啊..
Stamen says:
你说的这些也是要保证 ,但凡事有度
Stamen says:
事务的逻辑是业务上还是展现上的?
Unknow---- says:
问题我们做的架构,可以让开发人员不需要考虑事务了啊..因为底层已经都实现这种服务了
Stamen says:
你的事务都是一个Action方法一个事务吗?
Unknow---- says:
假如就在commonAction中实现了.开发人员继承一个action就可以获得事务服务了
Unknow---- says:
是啊..
Stamen says:
不跟你玩了
Stamen says:
一个Action方法一个事务,你这个大头
Stamen is searching for:
我要找我笑掉的大牙了
MSN Search says:
We couldn't find any sites containing "我要找我笑掉的大牙了 ". Try using different search words.
Unknow---- says:
呵..这就是我的架构设计思路..你可以考虑下..想想我为什么这么做..而不是一定要做到思想的完美无缺性..我觉的我实践的体会就是设计一定不要考虑做到设计的完美性.
Stamen says:
你也走极端了
Unknow---- says:
哈....这都是来源于实践中的设计.而不是凭空捏造的.当然都有来源了..
Stamen says:
那只能说我们见过的项目多太简单了
Unknow---- says:
也许吧..因为我把设计的简单化看的太重了,就是我的设计一定要保证生产率和质量的提高,我的最高设计原则就是这个.其他的不考虑.
Stamen says:
我现在的项目就不允许这种粗细度
Unknow---- says:
对哦..所以我就跟你说我们的环境跟国外的IT环境不一样哦..
Unknow---- says:
那一天有空,你可以把你的项目说给我听听..也许我会改变我的想法.
Stamen says:
我说个我现在项目的一个现实需求吧
Unknow---- says:
可以啊
Stamen says:
用户升级产品事务失败,将信息记录下来,并发Mail给管理员,
这里有三个业务,升级产品事务 记录场景数据事务 发Mail业务 但都通过一个Action方法处理
Unknow---- says:
如果记录场景数据失败,或者发email失败呢..
Stamen says:
框架的简单是在能够满足业务的需求的灵活性上来做,它有一个基础 ,而不是不择手段的简化 ,否则就象60年代的大炼钢铁 有产量没有质量了。
Unknow---- says:
但你要考虑国内的软件背景,一个业务系统软件究竟能用多久..不同的上下文,就有不同的设计..
Stamen says:
productSerivce.upgrade(product);
Stamen says:
try{
productSerivce.upgrade(product);
}catch( RuntimeException e)
{
productService.recordFailLog( product);
mailSender.send( mail);
}
Unknow---- says:
而且不是没有质量,我设计的最高原则就是软件生产率和质量的提高..
Unknow---- says:
然后呢
Stamen says:
你上面提的小小需求你的框架都满足不了了 还说质量和生产率 质量和生产率是要做对事的前提下
Unknow---- says:
错了哦..设计是依赖上下文的,老大..如果需求是这样的,当然设计要去改变了,难道一套设计就能走天下嘛....
Stamen says:
你的设计是要通用的,又不是只给一个项目用
Stamen says:
给一个项目用 就直接写JSP 也是可以的
Unknow---- says:
那你也极端了哦.. 这种我的架构也是可以做的..
Unknow---- says:
spring如何实现呢
Stamen says:
别的先不说,有两个解决思想是一定有问题的:
1)事务在Action层控制
2)事务粒度为一个请求
Unknow---- says:
那你说说问题的所在吧
Stamen says:
上面不都说了 笨
Unknow---- says:
没有吧..我怎么没发现啊..
Stamen says:
笨 笨 笨
Unknow---- says:
问题还是你怎么看待action了..
Unknow---- says:
那你用spring怎么解决
Stamen says:
Action负责两部分的功能 :
1) 页面流程控制 ,如失败转向哪儿 失败转向哪儿 等;
2) 业务流程控制 ,如上面我举的那个例子,成功升级后 如果处理 升级失败后 如果处理等
Unknow---- says:
你说的没错了..你的那些代码应该叫做应用组织逻辑..
Unknow---- says:
它不属于核心的业务逻辑..如果你把action来作为应用逻辑组成层的话.也是可以做到的
Stamen says:
Action并不是完全不负责业务 ,但它控制的业务逻辑是粗粒度的 是业务流程层面上的,而非事务流程层面
Unknow---- says:
当然了..spring的基于配置事务是很用的,我在青鸟中所教的架构,就是用spring的事务,当时也提到一个spring唯一能看到实用性的价值
Stamen says:
不说其实的,这一点已经很不错了
Stamen says:
其他
Stamen says:
你去给你们领导吹吹风吧,我到时给你们培训Spring
Unknow---- says:
呵..就像我说的上下文一样,如果上下文不一样,设计真的不一样,就像你提的,我在北大青鸟就是用spring解决的.但不用spring也是可以解决的.
Unknow---- says:
可以啊..没问题啊..不过要讲实用的..
Stamen says:
嗯 也是有一定的道理 ,不过我不相信电力的业务会那么简单
Unknow---- says:
不过讲下设计思想更好了
Unknow---- says:
电力业务没你想的复杂了.可能更简单..
Stamen says:
Xxx公司的开发人员水平还不太高 目前更突出的问题是开发实现上 设计思想和你聊就OK了
Stamen says:
如果事务是请求级别的 那就OK
Stamen says:
不过没有1K 不去讲哦
Unknow---- says:
是啊..但我是希望两个都有了,多讲下思想,对他们改变思想比较好..希望他们能听到好的思想,可以在项目中去体会..
Unknow---- says:
我帮你提下..
Unknow---- says:
不过不知道行不行哦.因为我以前就提过,但没成功..
Stamen says:
不要紧 可以随便说 我不一定有空
Stamen says:
想半年呆在家里 一边搞好生产 一边搞建设
评论
52 楼
daquan198163
2006-11-04
partech 写道
daquan198163 写道
Spring可以让我们这些菜鸟在不知不觉中享受AOP的好处,为什么要去用AspectJ做同样的事情呢,为了出去说自己用过AOP时底气更足?:)
还有Spring对web层和持久层框架的整合、简化异常处理、简化单元测试。。。如此多的好处一站式提供
还有Spring对web层和持久层框架的整合、简化异常处理、简化单元测试。。。如此多的好处一站式提供
AspectJ的使用要比Spring的配置简洁得多。使用Spring的AOP并不会不知不觉,原理是相同的。
还有你说的整合问题,Web没用过,没有发言权。同持久层的整合是鸡肋,有时还不得不直接访问。
简化异常处理是啥意思?单元测试还需要启动Spring麽?
这里说的单元测试,严格讲应该叫“集成单元测试”了,确实会启动Spring容器,参见江南白衣的幼学琼林--Spring下的单元测试要点
Spring对web层框架的整合:struts/ww/jsf可以随意切换,Equinox(同名,但不是那个Eclipse的项目)项目充分展示了这种能力,还有整合hibernate/iBATIS
简化异常处理:Spring提供了一种设计巧妙的异常处理机制,可以把底层抛的异常转换成runtime型的,使得应用代码及其简单,最明显的例子就是,虽然我在用着Hibernate,但我的DAO里根本没有Hibernate的异常,甚至没有import任何Hibernate的类;
现在人都很懒惰,程序员尤其懒惰而且据称是种美德,Spring提供了一站式解决方案而且解决的还挺优雅,所以能流行,那个AspectJ虽然某方面很厉害,但是他解决的问题太单一了,我这样的懒人一般不愿意投入精力去学
而且AspectJ不是已经合并到Spring2.0了吗,咱们还在这里争什么呢?
51 楼
hongliang
2006-11-04
完全没有意义的讨论。没有最好的library or framework,只有最合适的,哪个你觉得用着爽你就用哪个。我最初也觉得WebWork+Spring+Hibernate+Freemarker狠爽,现在把WebWork和Spring都踢走叻,因为用着多叻就觉得不爽叻,用起来太麻烦,索性自己写叻个框架,现在这个框架正用在公司的新产品中,不仅解决叻狠多以前Spring+Webwork的麻烦事,而且最重要的是大家都觉得用着狠爽,对我们自己的胃口。
下一步我要把Hibernate和Freemarker踢走,因为现在觉得它们俩个也碍事叻。
每个程序员都有自己的一套编程方式,有人喜欢麻烦点,有人喜欢直接点,有人喜欢规范点(如JSF拥蹩),有人喜欢灵活点。没有谁对谁错,自己用着爽就行叻。
就跟房子/车子/妻子/孩子一样,自己觉得好的那tmd就是好的!:D
下一步我要把Hibernate和Freemarker踢走,因为现在觉得它们俩个也碍事叻。
每个程序员都有自己的一套编程方式,有人喜欢麻烦点,有人喜欢直接点,有人喜欢规范点(如JSF拥蹩),有人喜欢灵活点。没有谁对谁错,自己用着爽就行叻。
就跟房子/车子/妻子/孩子一样,自己觉得好的那tmd就是好的!:D
50 楼
dwangel
2006-11-04
wobuzhi 写道
我就是那个所谓的朋友,看了大家的反馈,感觉收获蛮多的.不过,我想纠正下,其实我在04年就自己使用spring了,而且04年还建议过公司使用SPRING.而不像有些人想象的没使用过.:)
其实,在我现在看的书中,有两本是SPRING的书,你说我是排斥SPRING吗? 我从来不排斥,相反我很喜欢SPRING的思想,但是要让我在项目中使用SPRING,我没有足够的理由说服自己,周围的用SPRING的朋友也没有足够的理由,我也曾在网上寻找过这个答案,可惜没有找到一个人专门来阐述SPRING在国内项目中所带来的价值(不是写所谓的AOP,IOC,基于配置的事务等),而是带来看的着摸的到的价值,而不是仅仅说说而已的价值.我想hibernate框架为项目所带来的价值,大家在使用时都深刻体会到了吧,即使你只是使用hibernate来替代JDBC这个最基本的功能.但SPRING呢? 它为项目所带来的价值真的像国内很多人说的那样多吗?
我觉的我设计时最高的设计指导原则就是软件生产率和软件质量的提高,而不是所谓的可扩展性,灵活性,代码优雅,基于配置,面向切面,IOC等.我们一定要时时刻刻的牢记我们做软件的目的,这就足够了.而不是用SPRING,我就一定能为我的项目带来更多的价值,有时候大家能静下来反省下会更好,国内从来不缺少优秀的实践者,但往往缺少思考者.
那些EJB兴起的时候就说EJB好,HIBERNATE兴起的时候就说HIBERNATE好,SPRING兴起的时候就说SPRING好,这种人在国内太多了,为什么每个时期的流行思想都不是国内人提出来的呢? 不要仅仅实践实践再实践,为思考多留点时间吧..
其实,在我现在看的书中,有两本是SPRING的书,你说我是排斥SPRING吗? 我从来不排斥,相反我很喜欢SPRING的思想,但是要让我在项目中使用SPRING,我没有足够的理由说服自己,周围的用SPRING的朋友也没有足够的理由,我也曾在网上寻找过这个答案,可惜没有找到一个人专门来阐述SPRING在国内项目中所带来的价值(不是写所谓的AOP,IOC,基于配置的事务等),而是带来看的着摸的到的价值,而不是仅仅说说而已的价值.我想hibernate框架为项目所带来的价值,大家在使用时都深刻体会到了吧,即使你只是使用hibernate来替代JDBC这个最基本的功能.但SPRING呢? 它为项目所带来的价值真的像国内很多人说的那样多吗?
我觉的我设计时最高的设计指导原则就是软件生产率和软件质量的提高,而不是所谓的可扩展性,灵活性,代码优雅,基于配置,面向切面,IOC等.我们一定要时时刻刻的牢记我们做软件的目的,这就足够了.而不是用SPRING,我就一定能为我的项目带来更多的价值,有时候大家能静下来反省下会更好,国内从来不缺少优秀的实践者,但往往缺少思考者.
那些EJB兴起的时候就说EJB好,HIBERNATE兴起的时候就说HIBERNATE好,SPRING兴起的时候就说SPRING好,这种人在国内太多了,为什么每个时期的流行思想都不是国内人提出来的呢? 不要仅仅实践实践再实践,为思考多留点时间吧..
hehe
Rod Johnson自己在《J2ee 设计开发编程指南》里都是主张 问题驱动而不是技术驱动。
Spring的框架,应该说是针对某一类问题提供了一套解决方法。但是,同样的问题并非不能用其他方法解决。
应该说,使用spring,可以减少一些自己设计编写工具并且整合的工作量。
如果有一群同样技术水平,配合很默契的工程师,使用不使用spring,其实差别不大。
spring就像外面卖的工具包,螺丝刀钳子之类的都有。家用维修基本够了。一般人拿过来就能用。
但是,对一些专门工业的人来说,比如修汽车,他们用的工具从尺寸上,精细度上可能就不一样。有时候用惯了自己手里的工具,拿个大众化的工具,即使能干同样的事情,也觉得不习惯。甚至有人更喜欢自己定制工具,更顺手,更省力(对他个人,但不一定适合别人)。
49 楼
rockjava
2006-11-04
很无聊的话题,有意思吗?有价值吗?
48 楼
partech
2006-11-04
daquan198163 写道
Spring可以让我们这些菜鸟在不知不觉中享受AOP的好处,为什么要去用AspectJ做同样的事情呢,为了出去说自己用过AOP时底气更足?:)
还有Spring对web层和持久层框架的整合、简化异常处理、简化单元测试。。。如此多的好处一站式提供
还有Spring对web层和持久层框架的整合、简化异常处理、简化单元测试。。。如此多的好处一站式提供
AspectJ的使用要比Spring的配置简洁得多。使用Spring的AOP并不会不知不觉,原理是相同的。
还有你说的整合问题,Web没用过,没有发言权。同持久层的整合是鸡肋,有时还不得不直接访问。
简化异常处理是啥意思?单元测试还需要启动Spring麽?
47 楼
daquan198163
2006-11-04
Spring可以让我们这些菜鸟在不知不觉中享受AOP的好处,为什么要去用AspectJ做同样的事情呢,为了出去说自己用过AOP时底气更足?:)
还有Spring对web层和持久层框架的整合、简化异常处理、简化单元测试。。。如此多的好处一站式提供
还有Spring对web层和持久层框架的整合、简化异常处理、简化单元测试。。。如此多的好处一站式提供
46 楼
partech
2006-11-04
wobuzhi 写道
我就是那个所谓的朋友,看了大家的反馈,感觉收获蛮多的.不过,我想纠正下,其实我在04年就自己使用spring了,而且04年还建议过公司使用SPRING.而不像有些人想象的没使用过.:)
其实,在我现在看的书中,有两本是SPRING的书,你说我是排斥SPRING吗? 我从来不排斥,相反我很喜欢SPRING的思想,但是要让我在项目中使用SPRING,我没有足够的理由说服自己,周围的用SPRING的朋友也没有足够的理由,我也曾在网上寻找过这个答案,可惜没有找到一个人专门来阐述SPRING在国内项目中所带来的价值(不是写所谓的AOP,IOC,基于配置的事务等),而是带来看的着摸的到的价值,而不是仅仅说说而已的价值.我想hibernate框架为项目所带来的价值,大家在使用时都深刻体会到了吧,即使你只是使用hibernate来替代JDBC这个最基本的功能.但SPRING呢? 它为项目所带来的价值真的像国内很多人说的那样多吗?
我觉的我设计时最高的设计指导原则就是软件生产率和软件质量的提高,而不是所谓的可扩展性,灵活性,代码优雅,基于配置,面向切面,IOC等.我们一定要时时刻刻的牢记我们做软件的目的,这就足够了.而不是用SPRING,我就一定能为我的项目带来更多的价值,有时候大家能静下来反省下会更好,国内从来不缺少优秀的实践者,但往往缺少思考者.
那些EJB兴起的时候就说EJB好,HIBERNATE兴起的时候就说HIBERNATE好,SPRING兴起的时候就说SPRING好,这种人在国内太多了,为什么每个时期的流行思想都不是国内人提出来的呢? 不要仅仅实践实践再实践,为思考多留点时间吧..
其实,在我现在看的书中,有两本是SPRING的书,你说我是排斥SPRING吗? 我从来不排斥,相反我很喜欢SPRING的思想,但是要让我在项目中使用SPRING,我没有足够的理由说服自己,周围的用SPRING的朋友也没有足够的理由,我也曾在网上寻找过这个答案,可惜没有找到一个人专门来阐述SPRING在国内项目中所带来的价值(不是写所谓的AOP,IOC,基于配置的事务等),而是带来看的着摸的到的价值,而不是仅仅说说而已的价值.我想hibernate框架为项目所带来的价值,大家在使用时都深刻体会到了吧,即使你只是使用hibernate来替代JDBC这个最基本的功能.但SPRING呢? 它为项目所带来的价值真的像国内很多人说的那样多吗?
我觉的我设计时最高的设计指导原则就是软件生产率和软件质量的提高,而不是所谓的可扩展性,灵活性,代码优雅,基于配置,面向切面,IOC等.我们一定要时时刻刻的牢记我们做软件的目的,这就足够了.而不是用SPRING,我就一定能为我的项目带来更多的价值,有时候大家能静下来反省下会更好,国内从来不缺少优秀的实践者,但往往缺少思考者.
那些EJB兴起的时候就说EJB好,HIBERNATE兴起的时候就说HIBERNATE好,SPRING兴起的时候就说SPRING好,这种人在国内太多了,为什么每个时期的流行思想都不是国内人提出来的呢? 不要仅仅实践实践再实践,为思考多留点时间吧..
来搅一下浑水。
支持wobuzhi。
关于spring俺们就用了个Remoting,大部分使用AspectJ就更好的解决IOC的问题,只有很少几个使用了Spring的IOC,实际上也是可以通过Aspect搞定的,能够用就没管。
robbin 写道
那你如何管理Hibernate的SessionFactory获取,Session的打开和关闭,事务的控制呢?说说看吧
用一个Aspect截获service的方法就可以做到。
45 楼
dada
2006-11-04
wyse 写道
我是初学者,弱弱地请教一下:Spring 和 JBOSS Seam 有可比性吗?Spring自身或者里面的集成的开源框架中,哪个部分对应Seam集成的jBPM?
谢谢!
spring本身就可以很好的和jBPM集成。
44 楼
Gene
2006-11-04
wyse 写道
Gene 写道
nihongye 写道
是大家只爱spring,不爱其它的,其实各有各的精彩
Spring是不错, 不过它的流行占了EJB的便宜. Rod大哥如果没有打出j2ee without ejb的旗号首先不会吸引那么多人的注意. Spring的流行很大程度归功于Rod的两本书以及其他一些宣传方式. 我不否认spring带来的很多benefit, 但spring的缺点也不少. 所以一味鼓吹一种框架没啥意思, 自己用就行了, 没有必要到处宣传要别人也使用. 好不好, 由别人自己决定. 今后主流的开发java应用的架构,应该有两种, 一种是基于J2ee标准的架构就是jsf+ejb3, 还有一种就是spring加上一些其他开源框架. Spring这一边现在占据了优势, 如果说是技术上的优势, 不如说是抢了个j2ee规范没有出来的空挡的先发优势. 随着jsf, ejb3的成熟, 会有越来越多的人转向这个架构. 不过不会有哪方获取完全的胜利.
我是初学者,弱弱地请教一下:Spring 和 JBOSS Seam 有可比性吗?Spring自身或者里面的集成的开源框架中,哪个部分对应Seam集成的jBPM?
谢谢!
43 楼
wyse
2006-11-04
Gene 写道
nihongye 写道
是大家只爱spring,不爱其它的,其实各有各的精彩
Spring是不错, 不过它的流行占了EJB的便宜. Rod大哥如果没有打出j2ee without ejb的旗号首先不会吸引那么多人的注意. Spring的流行很大程度归功于Rod的两本书以及其他一些宣传方式. 我不否认spring带来的很多benefit, 但spring的缺点也不少. 所以一味鼓吹一种框架没啥意思, 自己用就行了, 没有必要到处宣传要别人也使用. 好不好, 由别人自己决定. 今后主流的开发java应用的架构,应该有两种, 一种是基于J2ee标准的架构就是jsf+ejb3, 还有一种就是spring加上一些其他开源框架. Spring这一边现在占据了优势, 如果说是技术上的优势, 不如说是抢了个j2ee规范没有出来的空挡的先发优势. 随着jsf, ejb3的成熟, 会有越来越多的人转向这个架构. 不过不会有哪方获取完全的胜利.
我是初学者,弱弱地请教一下:Spring 和 JBOSS Seam 有可比性吗?Spring自身或者里面的集成的开源框架中,哪个部分对应Seam集成的jBPM?
谢谢!
42 楼
robbin
2006-11-03
那你如何管理Hibernate的SessionFactory获取,Session的打开和关闭,事务的控制呢?说说看吧
41 楼
wobuzhi
2006-11-03
我就是那个所谓的朋友,看了大家的反馈,感觉收获蛮多的.不过,我想纠正下,其实我在04年就自己使用spring了,而且04年还建议过公司使用SPRING.而不像有些人想象的没使用过.:)
其实,在我现在看的书中,有两本是SPRING的书,你说我是排斥SPRING吗? 我从来不排斥,相反我很喜欢SPRING的思想,但是要让我在项目中使用SPRING,我没有足够的理由说服自己,周围的用SPRING的朋友也没有足够的理由,我也曾在网上寻找过这个答案,可惜没有找到一个人专门来阐述SPRING在国内项目中所带来的价值(不是写所谓的AOP,IOC,基于配置的事务等),而是带来看的着摸的到的价值,而不是仅仅说说而已的价值.我想hibernate框架为项目所带来的价值,大家在使用时都深刻体会到了吧,即使你只是使用hibernate来替代JDBC这个最基本的功能.但SPRING呢? 它为项目所带来的价值真的像国内很多人说的那样多吗?
我觉的我设计时最高的设计指导原则就是软件生产率和软件质量的提高,而不是所谓的可扩展性,灵活性,代码优雅,基于配置,面向切面,IOC等.我们一定要时时刻刻的牢记我们做软件的目的,这就足够了.而不是用SPRING,我就一定能为我的项目带来更多的价值,有时候大家能静下来反省下会更好,国内从来不缺少优秀的实践者,但往往缺少思考者.
那些EJB兴起的时候就说EJB好,HIBERNATE兴起的时候就说HIBERNATE好,SPRING兴起的时候就说SPRING好,这种人在国内太多了,为什么每个时期的流行思想都不是国内人提出来的呢? 不要仅仅实践实践再实践,为思考多留点时间吧..
其实,在我现在看的书中,有两本是SPRING的书,你说我是排斥SPRING吗? 我从来不排斥,相反我很喜欢SPRING的思想,但是要让我在项目中使用SPRING,我没有足够的理由说服自己,周围的用SPRING的朋友也没有足够的理由,我也曾在网上寻找过这个答案,可惜没有找到一个人专门来阐述SPRING在国内项目中所带来的价值(不是写所谓的AOP,IOC,基于配置的事务等),而是带来看的着摸的到的价值,而不是仅仅说说而已的价值.我想hibernate框架为项目所带来的价值,大家在使用时都深刻体会到了吧,即使你只是使用hibernate来替代JDBC这个最基本的功能.但SPRING呢? 它为项目所带来的价值真的像国内很多人说的那样多吗?
我觉的我设计时最高的设计指导原则就是软件生产率和软件质量的提高,而不是所谓的可扩展性,灵活性,代码优雅,基于配置,面向切面,IOC等.我们一定要时时刻刻的牢记我们做软件的目的,这就足够了.而不是用SPRING,我就一定能为我的项目带来更多的价值,有时候大家能静下来反省下会更好,国内从来不缺少优秀的实践者,但往往缺少思考者.
那些EJB兴起的时候就说EJB好,HIBERNATE兴起的时候就说HIBERNATE好,SPRING兴起的时候就说SPRING好,这种人在国内太多了,为什么每个时期的流行思想都不是国内人提出来的呢? 不要仅仅实践实践再实践,为思考多留点时间吧..
40 楼
stamen
2006-11-03
Gene 写道
nihongye 写道
是大家只爱spring,不爱其它的,其实各有各的精彩
Spring是不错, 不过它的流行占了EJB的便宜. Rod大哥如果没有打出j2ee without ejb的旗号首先不会吸引那么多人的注意. Spring的流行很大程度归功于Rod的两本书以及其他一些宣传方式. 我不否认spring带来的很多benefit, 但spring的缺点也不少. 所以一味鼓吹一种框架没啥意思, 自己用就行了, 没有必要到处宣传要别人也使用. 好不好, 由别人自己决定. 今后主流的开发java应用的架构,应该有两种, 一种是基于J2ee标准的架构就是jsf+ejb3, 还有一种就是spring加上一些其他开源框架. Spring这一边现在占据了优势, 如果说是技术上的优势, 不如说是抢了个j2ee规范没有出来的空挡的先发优势. 随着jsf, ejb3的成熟, 会有越来越多的人转向这个架构. 不过不会有哪方获取完全的胜利.
完全同意,Spring是在大家对EJB无限迷茫,不知所措后,适时出现的一缕清新的阳光,才使大家在短时间内从之如流。
39 楼
whisper
2006-11-01
同感
为模式而模式
真用的着的时候就不讨论了
为模式而模式
真用的着的时候就不讨论了
38 楼
Gene
2006-11-01
nihongye 写道
是大家只爱spring,不爱其它的,其实各有各的精彩
Spring是不错, 不过它的流行占了EJB的便宜. Rod大哥如果没有打出j2ee without ejb的旗号首先不会吸引那么多人的注意. Spring的流行很大程度归功于Rod的两本书以及其他一些宣传方式. 我不否认spring带来的很多benefit, 但spring的缺点也不少. 所以一味鼓吹一种框架没啥意思, 自己用就行了, 没有必要到处宣传要别人也使用. 好不好, 由别人自己决定. 今后主流的开发java应用的架构,应该有两种, 一种是基于J2ee标准的架构就是jsf+ejb3, 还有一种就是spring加上一些其他开源框架. Spring这一边现在占据了优势, 如果说是技术上的优势, 不如说是抢了个j2ee规范没有出来的空挡的先发优势. 随着jsf, ejb3的成熟, 会有越来越多的人转向这个架构. 不过不会有哪方获取完全的胜利.
37 楼
wolfigo
2006-10-31
To daquan198163:
1、请看上下文,什么时候有说过多用一种框架就多一些复杂性??
2、那重构是什么?请说说你的理解。
3、xP理解确是有误
4、我没说spring不好,请不要误解,呵呵。
PS:很认真地和你探讨,态度很端正。
1、请看上下文,什么时候有说过多用一种框架就多一些复杂性??
2、那重构是什么?请说说你的理解。
3、xP理解确是有误
4、我没说spring不好,请不要误解,呵呵。
PS:很认真地和你探讨,态度很端正。
36 楼
s5kk
2006-10-31
上次碰到个无法使用spring的项目,总结到的经验就是:
没有spring是可以的,但是没有aspectj是万万不行的。
看到spring2.0和aspectj如此“和谐”,感觉怪怪的。
没有spring是可以的,但是没有aspectj是万万不行的。
看到spring2.0和aspectj如此“和谐”,感觉怪怪的。
35 楼
zrweng
2006-10-31
ajoo 写道
还有构造函数注射。知道为什么很多人反感pico么?一个原因是它自己觉得自己了不起,喋喋不休地说构造器注射比setter注射好,spring好就好在不做这种价值观的判断,setter/ctor都支持,你爱用哪个用哪个。
所以什么推荐使用的话没什么意义。很多时候应该是具体应用决定工具,而不是反过来。我需要用构造器,因为系统本来就是用构造汉书设计的。不能因为你spring推荐就改我的设计,这就叫侵入性了。
为什么我不自己实现这个功能呢?
1。比较麻烦
2。ctor autowiring是spring已经实现的功能。要求我重复实现一遍而不是重用已经做好的,好像不太合理。就是spring如果实现这个功能的时候不是重用原有的代码,而是重新再写一遍,也是bad smell。
当然,yan是可以处理这种需求的。这个功能在我们重构遗留系统的时候也发现还是有实际价值的。
说到心坎上了!!
34 楼
netfishx
2006-10-31
ajoo 写道
睁眼看看spring2的这个基于namespace的自定义tag吧。实现起来麻烦无比,要写一坨坨的乌七八糟的代码(http://www.iteye.com/topic/30964),又强迫我用恶心的xml namespace。如果要实现这么一点普通的功能就让我吭哧吭哧地干体力活,这不是一夜回到解放前了?
rod老哥为什么不学学ant,看几百年前人家是怎么作自定义tag的。
rod老哥为什么不学学ant,看几百年前人家是怎么作自定义tag的。
说得太对了!!!
33 楼
daquan198163
2006-10-31
wolfigo 写道
dada 写道
竟然看完了。你朋友很多基本的spring和acegi的概念都没有搞清。真是不明白为什么可以对自己不了解的东西妄下断言呢?
何谓很多基本的spring和acegi的概念?spring,acegi只是为你做了N多的事情,留给你的只是一定量的配置,若干的代码量而已。有什么新东西吗?甚至可以说和ajax的产生没什么区别,唯一的好处就是其体现出来的设计思想,可有一些也是借鉴而已。
不是所有的项目都“体大如牛”的,从实用角度考虑,什么方便用什么,现在可用的东西那么多,需要什么我拿来用就是了,只要能简单,正确地表达出我某一个交易要做什么,不能做什么,与其他交易或其他系统中的业务是否发生关联,如何通讯就可以了。
重构只是一个美好的愿望,全中国有那么多的业务系统,大多数都是一个版本一个版本迭代出来的产物,你觉得上一个版本有bad smell,代码冗余,耦合极强,难道你就去重新构造这个业务系统?等你重新构造后,它的市场价值也没了,投产还有何意义?你所做的一切还有何意义?所以我觉得重构对提高个人代码素养有很大的好处,对实际的业务系统意义不大。
再来说说XP,所谓的“结对编程”,国外不晓得乍应用的,对于国内,乍应用,一个开发,一个辅助,两人轮换,可对于开发,每人都有自己的一套小九九,对于不同的需求,每人都有不同的理解,估计要两人能达到一致,恐怕就得耗费一段时间了,在开发过程中也难免不会出现意见的分歧,这样情况如何解决?老外是怎样解决的?也许你会说,每人做一个交易,一个流程,这样就不“打架”了,貌似可行,可前提是这两人得“对眼”,要么能力接近,要么关系不错,否则如何解决两人的合作关系?除非是一男一女合作。。。。。。
随便说说,欢迎讨论。。。。。另外回贴的时候,不知为何cpu占用过高,风扇时不时地在转,我用的maxthon,没开其它东西,噢,对了,开空调来的:)怀疑是文本编辑器有资源占用问题,呵呵。
太多的误解了。
关于简单:你似乎认为多用一种框架就多一些复杂性,所以你做简单的东西就没必要用,体现实用主义。
其实spring一个最大的优点就是简单,可以大大减少代码量
关于重构:从你举的例子可以看出你完全不知道什么是重构,你说的那个是重写。
关于结对编程:你说“每人都有不同的理解,估计要两人能达到一致,恐怕就得耗费一段时间了”
难道这个时间浪费了吗,这不正是明确需求的过程吗,难道每个人在需求不明、缺少讨论的情 况下开始工作不是最大的浪费吗?
最后:你似乎也不理解Spring对可测试性带来的巨大好处,以及可测试性本身的重要性。
还是对Spring深入了解了以后再下论断吧,不要老是随便说说,这是态度问题!
发表评论
-
一个常见的Spring IOC疑难症状
2013-07-25 14:14 5025Case 请看下面的IOC实例: 1)Aa ... -
mybatis3.1分页自动添加总数
2013-07-08 21:11 22810问题 1.mybatis默认分页是内存分页的,谁用谁崩溃啊! ... -
学习Spring必学的Java基础知识(9)----HTTP请求报文
2012-06-09 16:02 13913引述要学习Spring框架的技术内幕,必须事先掌握一些基本的J ... -
学习Spring必学的Java基础知识(4)----XML基础知识
2012-05-12 15:33 8544引述要学习Spring框架的 ... -
学习Spring必学的Java基础知识(3)----PropertyEditor
2012-05-12 15:13 16827引述要学习Spring框架的 ... -
学习Spring必学的Java基础知识(2)----动态代理
2012-05-02 13:03 9670引述要学习Spring框架的 ... -
学习Spring必学的Java基础知识(1)----反射
2012-04-25 13:57 89740引述要学习Spring框架的技术内幕,必须事先掌握一些基本的J ... -
透透彻彻IoC(你没有理由不懂!)
2012-04-18 11:01 94157引述:IoC(控制反转:I ... -
单元测试系列之5:使用unitils测试Service层
2012-04-14 10:48 18418引述:Spring 的测试框架为我们提供一个强大的测试环境,解 ... -
如何用Spring读取JAR中的文件
2012-04-13 17:22 18365使用如下方式读取JAR中的文件出错 类路径下 ... -
单元测试系列之3:测试整合之王Unitils
2012-04-09 14:11 15605引述:程序测试对保障应用程序正确性而言,其重要性怎么样强调都不 ... -
单元测试系列之1:开发测试的那些事儿
2012-03-28 12:52 9999引述:程序测试对保障应用程序正确性而言,其重要性怎 ... -
单元测试的那些事儿
2012-03-28 12:48 2------------------------------- ... -
Spring 3.0的新功能
2012-03-26 09:30 71772009年9月发布Spring ... -
Spring的事务管理难点剖析(7):数据连接泄漏
2012-03-07 10:53 6818底层连接资源的访问问题 对于应用开发者来说,数据连接泄 ... -
Spring的事务管理难点剖析(6):特殊方法成漏网之鱼
2012-03-07 09:28 4531哪些方法不能实施Spring ... -
Spring的事务管理难点剖析(5):联合军种作战的混乱
2012-03-07 09:10 7840Spring事务管理器的应对 Spring抽象的DA ... -
Spring的事务管理难点剖析(4):多线程的困惑
2012-03-06 17:30 16889Spring通过单实例化Bean简化多线程问题 由于 ... -
Spring的事务管理难点剖析(3):事务方法嵌套调用的迷茫
2012-03-06 17:23 10568Spring事务传播机制回顾 ... -
Spring的事务管理难点剖析(2):应用分层的迷惑
2012-03-06 16:59 5106Web、Service及DAO三 ...
相关推荐
Spring Boot WebChat 网页聊天室是一款基于Spring Boot框架构建的应用,整合了Spring Security、Spring Data JPA、Thymeleaf以及Spring WebSocket等技术,为用户提供了一个实时的在线聊天平台。下面将详细介绍这些...
在"Spring Boot一对一聊天"项目中,我们关注的是构建一个实时的、双向通信的聊天应用,这通常涉及到WebSocket技术。 WebSocket是一种在客户端和服务器之间建立长时间连接的协议,允许双向数据流。在Spring Boot中,...
本项目基于Spring平台,整合websocket协议,实现一个简易web聊天室的功能。主要特性如下: 1.包含聊天室登录、退出的功能。登录时,浏览器自动向服务器发起websocket连接,退出时自动切断。 2.登录后,用户可查看到...
本文将深入探讨如何利用Mina作为网络通信库,Spring作为应用框架,构建一个功能完备的聊天室系统。 Mina(Java Minimal Asynchronous Network Application Framework)是一个开源的、轻量级的网络通信框架,它提供...
【标题】"spring+mybatis+springmvc+ajax简单聊天室"揭示了这是一个基于Java技术栈构建的在线聊天室应用。这个项目的核心是利用Spring框架的各组件(Spring、MyBatis、SpringMVC)来处理后端逻辑,并通过Ajax实现...
总结起来,Spring3和DWR3结合使用,可以高效地构建出一个实时的在线聊天应用。Spring提供稳定的服务层支持,而DWR则负责实现高效的客户端和服务器通信,尤其是Server Push特性,使得聊天功能更加实时和流畅。通过...
1.文件用maven的方式导入到MyEcplise 直接运行Application里面的mian函数 2.然后用cmd的命令ipconfig 查看本地id 3.localhost://8080/index2.html/UID=3(localhost 换成本地ip,UID 用来模拟当前...4.多台电脑访问吧
在"spring websocket在线聊天demo"中,我们主要探讨的是如何利用Spring框架集成WebSocket,创建一个功能完备的在线聊天应用。 1. **Spring WebSocket概述** Spring框架提供了对WebSocket的支持,通过`spring-...
标题中的“flex结合spring activemq做了一个简易聊天室”涉及到的是使用Adobe Flex技术构建前端UI,通过Spring框架与ActiveMQ消息中间件进行通信,实现一个简单的聊天室应用。这个项目是一个很好的示例,展示了如何...
总的来说,"web spring boot 网页聊天器"是一个融合了Spring Boot、WebSocket技术和前端交互设计的项目,它展示了如何在Web环境中实现高效的实时通信,对于学习和理解现代Web应用的开发流程和技术栈有着很高的参考...
总结来说,这个项目展示了如何结合SpringCloud的微服务架构、Netty的高效通信、MQ的消息中间件和MySQL的数据存储,构建一个完整的分布式即时聊天系统。对于学习者而言,深入理解这些技术的原理并实践该项目,将有助...
核心技术采用Eureka、Fegin、Ribbon、Zuul、Hystrix、Security、OAth、Mybatis、Ace-cache等主要框架和中间件,UI采用Bootstrap、jquery等前端组件 spring boot项目是使用spring boot + thymeleaf 开发个人博客项目
总的来说,这个案例展示了OSGI的模块化优势,以及如何将Spring、Mybatis和Spring MVC集成到OSGI环境中,构建一个可维护、可扩展的登录应用。通过实践这样的案例,开发者可以更好地掌握这些技术在企业级开发中的应用...
在这个提供的压缩包文件中,名为"batch"的文件可能包含了一个简单的Spring Boot和Spring Batch整合的示例项目。这些文件可能包括Java源代码、配置文件以及可能的测试用例。通过查看这些文件,你可以学习如何将批处理...
在这个名为 "mysecurity" 的压缩包中,很可能是包含了一个实际的Spring Security配置和示例项目,我们可以从中学习到Spring Security的多个关键知识点。 首先,Spring Security的核心概念包括认证(Authentication...
总的来说,这个Java互联网实时聊天系统结合了Spring的强大后端能力、Netty的高效网络通信和WebSocket的双向实时通信特性,构建了一个健壮、高性能的聊天平台。通过合理的架构设计和优化,可以满足大量用户同时在线...
【Spring + DWR 无刷新...这个项目是一个很好的学习资源,它演示了Spring和DWR如何协同工作,创建一个实时的、交互式的Web应用。开发者可以通过研究源代码,了解如何在实际项目中应用这些技术,提高Web应用的用户体验。