|
锁定老帖子 主题：Spring--也许正成为一个EJB
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-15
还是自定义适合自己的框架吧，spring比较大众话，但架构思想比较好
|
| 返回顶楼 | |
|
发表时间：2011-04-15
hsiss 写道 spring是为了弥补java语言的缺陷产生的,如果使用java语言开发的话,用什么全栈式框架都是一样
1.java语言没有全局变量,而容器本身就是全局的,所以必须要有类似全局变量的概念,所以就出现了ioc(进化历程请看without ejb,有详细介绍,从多sington模式到一个sington的factory模式模式到没有sington的ioc) 2.java语言没有闭包,所以要有aop,什么声明式事务等等,其实都没有解决问题,或者说在java领域是无解的 由以上两点自然引申出来下一个 3.java做的架构只能是贫血模型,所以要有dao 本着大而全、小而全和要做就做全套的精神,orm,web,mvc和其他实用工具包自然就被包含进来了 有时想想，如果用javascript做架构的话都不会这么复杂 但是我们还在使用java，所以我们要用spring或者类似的框架 哥笑了，Spring 是用Java写的，弥补Java语言的不足？ 1.需要全局变量吗？要知道好的容器都提供了Context，Tomcat、Cache不是吗？自己不能实现？ 2.这个闭包有什么关系？Java语言没有提供API？Spring在JDK 1.2的时候就出来了？事务EJB没有？ 3.Java只能做贫血模式，JSF，EJB算什么呢？ 你说了这些都和设计有关，和有没有Spring没有一点关系。要知道Spring是Java写的，就好比名词解释，不能用自己解释自己一般。 |
| 返回顶楼 | |
|
发表时间：2011-04-15
ricoyu 写道 引用 但是我看到的情况都是在滥用。为一个功能写一个接口和一个实现类，然后就认为是面向接口编程。这种思路怎么来的，真正用的好吗？我是比较怀疑的。
LZ这段话我超级赞同的, 很多项目都是为了面向接口编程而面向接口编程, 庸人自扰之. 比如很多项目喜欢弄一个service接口, 然后对应一个serviceImpl实现类, 在action里持有这个service接口, 然后通过spring注入唯一的一个实现类serviceImpl, 这就是他们所谓的面向接口编程了. 在这种场景下完全不需要抽象出一个接口, 直接一个service具体类就ok了 同意！！！现在很多项目为了接口而接口，每个具体类都一定要整一个接口，为了接口而接口。实际上很多项目仔细一检查就会发现：接口和实现类的数量是1:1，而不是1：n(n是>1的浮点数)。如果都是1:1，就让人很怀疑这个接口的必要性了：1增加了代码量和复杂度；2增加了配置影响了性能。 |
| 返回顶楼 | |
|
发表时间：2011-04-15
superhanliu 写道 ricoyu 写道 引用 但是我看到的情况都是在滥用。为一个功能写一个接口和一个实现类，然后就认为是面向接口编程。这种思路怎么来的，真正用的好吗？我是比较怀疑的。
LZ这段话我超级赞同的, 很多项目都是为了面向接口编程而面向接口编程, 庸人自扰之. 比如很多项目喜欢弄一个service接口, 然后对应一个serviceImpl实现类, 在action里持有这个service接口, 然后通过spring注入唯一的一个实现类serviceImpl, 这就是他们所谓的面向接口编程了. 在这种场景下完全不需要抽象出一个接口, 直接一个service具体类就ok了 同意！！！现在很多项目为了接口而接口，每个具体类都一定要整一个接口，为了接口而接口。实际上很多项目仔细一检查就会发现：接口和实现类的数量是1:1，而不是1：n(n是>1的浮点数)。如果都是1:1，就让人很怀疑这个接口的必要性了：1增加了代码量和复杂度；2增加了配置影响了性能。 这个不能这么说，如果是项目之间有远程调用的话，接口还是必要的，即使是1:1。如果是自娱自乐，那就算了！ |
| 返回顶楼 | |
|
发表时间：2011-04-15
最后修改：2011-04-15
BigBlue 写道 axeon 写道 楼主的观点是正确的，但是你注定要被投新手和隐藏。
为spring叫好的，才真的是新手，不单单对java的历史没有比较，很多在开发语言层面上也没有比较。刚入行就做java，直接就做spring。 你若真的让他用别的语言写个东西，立刻六神无主，如若让他不用spring写java的东西，他也同样六神无主。 这姑且也算是斯德哥尔摩综合征之一吧！ 楼主被投新手和隐藏的原因是新手的基数还真的很大，而且很爱发言。 ejb我算是国内第一批用的，做了几个大项目，平心而论，不是那么好用，也不是那么难用。 spring也是国内第一批用的，其实本质上和ejb差不多，一个解决了A问题，带来了B问题，一个解决了B问题，带来了C问题。 但是，我就弄不明白了，spring难道是你亲爹，那么维护着？ 比较贴切的评价 我们团队就有这个现象，离了Spring就不会写东西，结果把什么东西都跟Spring搅在一起了，用Webservice要Spring才能用，用个JPA要Spring才能用，很无奈！ 这个实在要顶，"Spring控"们离开了Spring，连RMI都不知道是用来做什么的？然后通过Spring认识了RMI，就说RMI的所有特性都是Spring赋予的，这好比发生地震你被压在楼板下，消防员把你救出来了，你却对一只蟋蟀三拜九叩。 这个例子都举过多次，每次都被喷个十几楼。这次楼主提出了这个标题，我看喷楼主的人也快十楼了，看来ITEYE的 javaer们除了喷人和脏话，别得都不擅长啊。 另外，说点实际的：Spring的主要作用“解藕”，这个我想说的是：在实际的项目中，有几个接口的实现类是在后期需要变动的？真正的项目中，宁可动硬件去迎合软件实现，也不敢轻易改变软件内的实现。除非你做的项目 一个月要换八个客户，改变十几种功能，否则你的“解藕”根本就是为当初的开发人为设置了过多的绊脚石。 说得更具体一点，DAO我从来是使用一个通用DAO，根本不需要DAO层接口，Service层后期需要扩展的可能性是最大的，随意Service层可以用一下接口，但是也不一定非要用。 至于控制层，那是根本就不需要接口，我不知道控制层用接口来隔离是为了什么？有谁会做好的Struts2项目，后期硬生生的换成JSF或者其他的控制模式？ 所以把众多的实现都用接口代替，然后使用Spring的配置文件，或者annotation一个个注入实现类，或者使用autowire 自动注入实现类，都是不必要的开销。 更实际一些：你可以把项目中，后来可能要改变的实现类的调用处，全部换做上自己的annotation注解，后期，如果项目需要替换某些实现类，可以使用Google guice或者自己写的一个DI工具，把自己标注annotation的类替换掉； 如果项目不需要替换实现类，那就让项目顺畅地跑着。 总体的思路是：我想DI时，才去DI谁，大部分时间我都不DI，所以我也不需要为了未来可有可无的DI做那么多准备，配置那么多文件，做那么多接口。 |
| 返回顶楼 | |
|
发表时间：2011-04-15
Spring又没有逼着你非得写接口！
|
| 返回顶楼 | |
|
发表时间：2011-04-15
linvar 写道 ricoyu 写道 引用 但是我看到的情况都是在滥用。为一个功能写一个接口和一个实现类，然后就认为是面向接口编程。这种思路怎么来的，真正用的好吗？我是比较怀疑的。
LZ这段话我超级赞同的, 很多项目都是为了面向接口编程而面向接口编程, 庸人自扰之. 比如很多项目喜欢弄一个service接口, 然后对应一个serviceImpl实现类, 在action里持有这个service接口, 然后通过spring注入唯一的一个实现类serviceImpl, 这就是他们所谓的面向接口编程了. 在这种场景下完全不需要抽象出一个接口, 直接一个service具体类就ok了 开始的时候我也这样认为,后来在一个项目中果断去掉接口, 直接一个service具体类, 但是再后来才发现自己错了,接口的编程模式不是凭空而来的,是最佳实践... 特别是在项目大一点的时候, 另外我使用spring也是因为要取他的事务管理, 后来尝试struct2, springmvc, 最后选择springmvc. spring基本上是使用注释, 只有一个主配置文件,主要是配置数据源,事务管理. 基本就是使用springmvc + spring + mybatis组合, 是注解吧。 |
| 返回顶楼 | |
|
发表时间：2011-04-15
对头
spring最主要的误用是对于面向接口编程这块？ Rod等本意是面向抽象编程的 无奈的是 java里面正好有interface关键字 内流满面了 无数码农当圣经了 一个模块的服务等等 就是一个人用要接口干什么不是纯粹没事找抽型的吗？ 还有一大堆的dao层 这种东西完全可以抽象出来的 spring架构非常优秀这是不用质疑的 基本上能够将所有的开源软件融合进来 而且提供简便开发 对于依赖的解耦(ioc) 如果没有ioc你要想想你 为了实例化一个对象你要建立多少工厂类等等 要new对象对象才能将功能组装完 你还看到那种框架能够 ejb 用起来就蛋疼 |
| 返回顶楼 | |
|
发表时间：2011-04-15
我也觉得spring的配置文件，太多太麻烦了。不过总体上还是比较好用的
|
| 返回顶楼 | |
|
发表时间：2011-04-15
很赞成楼主的部分观点，我很讨厌SPRING的配置方式，虽然他的一些声时式注入相当好用，但是维护起来，反倒成本有点高了。
相比Spring前生的那本《without EJB》中的代码却是相当的经典，不过Spring的不断发展，将某些不该发展的地方过分发展了。 但是一个东西存在必有它存在的理由 |
| 返回顶楼 | |
