|
锁定老帖子 主题：Spring--也许正成为一个EJB
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-14
BigBlue 写道 linvar 写道 开始的时候我也这样认为,后来在一个项目中果断去掉接口, 直接一个service具体类, 但是再后来才发现自己错了,接口的编程模式不是凭空而来的,是最佳实践... 特别是在项目大一点的时候, 个别情况可能接口是必须的，但是大部分接口都是浪费 linvar 写道 另外我使用spring也是因为要取他的事务管理, 后来尝试struct2, springmvc, 最后选择springmvc. spring基本上是使用注释, 只有一个主配置文件,主要是配置数据源,事务管理. 基本就是使用springmvc + spring + mybatis组合, 事务管理有很多办法，不一定非要Spring吧。 另外说到事务管理，EJB做的绝对要比Spring好，实际用一下就知道了 如果是API级别的，通过提供接口，告知客户端怎么调用接口，他们不需要关心实现。如果是自娱自乐，定义太多接口是没有意义的。 务实地做法是，先提供实现，然后再抽象接口，不要为了接口而接口。 |
| 返回顶楼 | |
|
发表时间：2011-04-14
引用 如果说从interface中看出了非常具体的功能，那么这个interface其实就没有什么意义
我觉得这挺有道理 |
| 返回顶楼 | |
|
发表时间：2011-04-14
zdmcjm 写道 为毛oracle付费，java也有不需要javaee的解决方案，如playframework框架，根本不需有所谓的xxx容器，xxx中间件，xxx注入。
ioc个毛线。 用了ioc就叫解耦？ioc所代来的问题就是，没有容器，你这个类根本就不算一个类，只能说是个严重残疾的类，没有容器，就不能自理了。用ioc还有个毛病就是，让你很容易误用接口，要是需要注入的属性类型不声明成接口，你用ioc干什么呢？用了ioc，你不声明为接口，这跟直接new有什么区别？ 你用ioc你就去搞接口吧，搞annotation,置xml吧，spring所声称的解耦，是一个笑话。 spring代来了解耦，解什么耦，你不是被spring牵着鼻子走吗？ 我倒是觉得，spring最好用的不是什么ioc，什么aop，而是那些模版类，它给你的方便是实实在在的，确实减少了很多重复的代码量。而不是像ioc这种，减少了"new"而增加了一大堆xml,annotation，解耦个毛。 另外，楼主我支持你。 那些模版类确实是Spring的精华 |
| 返回顶楼 | |
|
发表时间：2011-04-14
最后修改：2011-04-14
Spring中有不少东西，还是非常不错的，比如它的Proxy,Template,Transaction等。
我也不反对用这些东西。 但现在的问题是，大家这部分其实用得不多，恰恰是不必要的接口设计了一堆。 如果说更好的方案，Tuscany可比我们一般的系统要复杂地多，但人家用了ServiceLocator这个简单的设计就解决了问题。 所以现在把Spring当成一个放之四海而皆准的东西，才是大家要思考的问题。 问题不在于Spring的场合，而是在于我们有没有去考虑这些场合是否该用Spring。 引用 什么是重量级，什么是轻量级？不要口号，要实际
重还是轻，其实没有什么一致的标准。 事实上，当场景复杂的时候，想轻是不太可能的。 Commons-Lang非常轻，但它的场景能和复杂的事务系统比吗。 现在Spring的功能也是非常多，也有上百M的Jar了吧。 如果说大家能分清楚自己需要的Spring模块，也罢了，但现在是吗？大部分情况正好相反吧！ 现在一个比较复杂的系统，如果用JBoss+Spring，大家觉得启动快吗？ |
| 返回顶楼 | |
|
发表时间：2011-04-14
我同意楼主观点，在开发中，其实很多时看的是项目需要才选用什么技术，不是一种技术就是万能的应用的，不过现在的java方向，还是很多都要求会spirng的，至少你的老板是这样想的。
|
| 返回顶楼 | |
|
发表时间：2011-04-15
楼主能评价出来spirng的一些误用.滥用.说明你用过,但是你评价出来的这几点.也正好说明你也只是用到了spirng的皮毛.
也就是说.你用的这些个皮毛.其实完全没必要使用spirng都可以实现,或者有更好的办法实现.说以楼主才发了这个帖子. 大家没必要跟帖了.万事万物,一物克一物,天生我才必有用.spring的精华不是楼主你这么两三句就给其否定了. |
| 返回顶楼 | |
|
发表时间：2011-04-15
大家可以花点点时间了解一下 EJB 3.x哦? 再回头看看 Spring 的优势
|
| 返回顶楼 | |
|
发表时间：2011-04-15
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或者类似的框架 |
| 返回顶楼 | |
|
发表时间：2011-04-15
最后修改：2011-04-15
ricoyu 写道 linvar 写道 ricoyu 写道 引用 但是我看到的情况都是在滥用。为一个功能写一个接口和一个实现类，然后就认为是面向接口编程。这种思路怎么来的，真正用的好吗？我是比较怀疑的。
LZ这段话我超级赞同的, 很多项目都是为了面向接口编程而面向接口编程, 庸人自扰之. 比如很多项目喜欢弄一个service接口, 然后对应一个serviceImpl实现类, 在action里持有这个service接口, 然后通过spring注入唯一的一个实现类serviceImpl, 这就是他们所谓的面向接口编程了. 在这种场景下完全不需要抽象出一个接口, 直接一个service具体类就ok了 开始的时候我也这样认为,后来在一个项目中果断去掉接口, 直接一个service具体类, 但是再后来才发现自己错了,接口的编程模式不是凭空而来的,是最佳实践... 特别是在项目大一点的时候, 另外我使用spring也是因为要取他的事务管理, 后来尝试struct2, springmvc, 最后选择springmvc. spring基本上是使用注释, 只有一个主配置文件,主要是配置数据源,事务管理. 基本就是使用springmvc + spring + mybatis组合, 不知道你的大项目是多大, 我做过的一个项目开发+测试+报表人员, 最多的时候达到上百个, 做了三年才上线, 所谓的service层根本就不抽象出接口来, service层是干嘛的?是"你"实现业务逻辑的地方, 而不是给团队里其他人用的, 分层干嘛?吃饱了撑的给自己找不痛快? 模块间需要调用对方的API, 那么需要提供一个interface给对方用, 自己提供一个实现类做具体的事, 这样最大限度地避免了模块间的耦合. 可能我理解错了, 我以为你说service,handler,dao层都不使用接口, service层不使用接口可能还行, handler, dao层不使用接口那就是自作自受了, 我觉得使用接口的话,从service层(代表需求)往回写条理比较清晰... |
| 返回顶楼 | |
|
发表时间：2011-04-15
看到这个标题的第一反应： 自己当时用Spring时为什么就没能这么明确地提出对Spring的批评意见？而只是崇拜地景仰？
|
| 返回顶楼 | |
