67,514
社区成员
发帖
与我相关
我的任务
分享诚心请教：spring到底好在哪里？使用spring的理由是什么？
最近很困扰：spring到底好在哪里？使用spring的理由是什么？
望大虾们指定一二，先谢了。
望大虾们指定一二，先谢了。
...全文
请发表友善的回复…
发表回复
zxj828282 2009-10-14
- 打赏
- 举报
目前spring我都没玩顺
jun_12 2009-10-14
- 打赏
- 举报
[Quote=引用 42 楼 bao110908 的回复:]
下面这些是原来在http://topic.csdn.net/u/20090504/17/969c7340-ebbe-4b79-b579-2d4563bb6de7.html 这个帖子中的回复，有兴趣的话可以看一下。
下面是我对一些开源框架的观点：
Spring
优点：IoC、AOP 容器，集大成者，集众框架，可谓包罗万象，应有尽有，学习资料丰富
缺点：极其繁杂的配置文件，原来有个 Spring 的项目，配置文件就有 8000 多行，可以把人看晕掉，极其不喜欢！大事小事都得弄个接口，感觉是为了接口而接口，估计有好多人是先写类再写接口的吧？复杂的配置文件与过度的分层直接导致的后果就是开发效率低下！
Hibernate
优点：ORM 的领头羊，ORM 事实上的标准，功能完善，学习资料丰富
缺点：在效率上有些问题，加之含有许多的 hbm 配置文件强行与实体代码分隔。
Struts 1.x
优点：老牌 MVC 框架，MVC 事实上的标准
缺点：说实在的我感觉除了比 Servlet 少在 web.xml 中配置一些东西、自动封装 FormBean 之外，没感觉到有什么好处，这个框架最不好用的就是它的标签，除了 html 标签好用之外，其他的标签极其不好用，特别是 logic:iterator 远远没有 c:forEach 用起来舒服。
Struts 2.x/WebWork 没用过。
JBoss Seam
优点：
完全打破三层体系架构，借助于 JSF 采用两层结构，页面层和组件层，Seam 是按照业务逻辑来分层，而不是按照架构来分层。
Seam 的最低版本是在 JDK 1.5 之上设计的，使用了很多 JDK 1.5 的新特性，大量地使用 Annotation，这种方式完全可以取代复杂的配置文件。就算是其中的日志组件也是采用变参实现的，这样我们就不用在页面上写 if(log.isDebugEnabled()) 了。
采用严格 xml 格式的 xhtml JSF 页面，将 JSF 原本的配置分散到每个页面的 .page.xml 文件中，可以在里面写些：进入页面时需要执行的方法、有哪些参数需要传递的、页面如何导航等等。
Seam 拥有完善权限模型，权限不仅可以在页面中表现，也可以通过 Annotation 在方法上限制该方法的执行权限。
Seam/JSF 中的 Backing Bean 可以是普通的 Java Bean，也可以是 Session Bean，这样就可以让 Seam 工程不仅能运行在 EJB 容器中，也可以运行在 Servlet 容器中。
Seam 中扩充了 Servlet 中的请求范围，增加了 Conversation、Process，而不是 Servlet 中的 application, session, request, page 四种。最常用的是 Conversation 这表示一个业务逻辑的作用范围，比 Session 小，比 Request 大。这种扩充完全是为了一整步骤的业务逻辑而定制的。
想想看使用 Seam 可以使用 Seam Gen 或者是 JBoss Tools 的 Eclipse 插件产生某个表的增删改查分页功能，如果不涉及业务逻辑，而且使用默认的模板可以一行代码不用写，快速开发，诱人吧 ^_^
以 JBoss Seam 为蓝本，其作者 Gavin King 提交的 JSR 299 -- WebBeans (Java Contexts and Dependency Injection) 已经被 JCP 采用，作为 Java EE 6 中的一部分。
缺点：
学习难度相对于 SSH 大很多，学习资料相对较少，其中所使用的 JSF 不用说了，相对于 Hibernate，Seam 所使用的 JPA 也是需要一定阶段地学习才能灵活使用的。其中还有多如牛毛的 Annotation、双向注入、 WebBeans 等概念也是需要一定时间来掌握的。
Seam 中所使用的页面组件框架，比如 Ajax4JSF, RichFaces 等等也是需要一定时间来掌握的。
[/Quote]
JBoss Seam
对我很有吸引力
下面这些是原来在http://topic.csdn.net/u/20090504/17/969c7340-ebbe-4b79-b579-2d4563bb6de7.html 这个帖子中的回复，有兴趣的话可以看一下。
下面是我对一些开源框架的观点：
Spring
优点：IoC、AOP 容器，集大成者，集众框架，可谓包罗万象，应有尽有，学习资料丰富
缺点：极其繁杂的配置文件，原来有个 Spring 的项目，配置文件就有 8000 多行，可以把人看晕掉，极其不喜欢！大事小事都得弄个接口，感觉是为了接口而接口，估计有好多人是先写类再写接口的吧？复杂的配置文件与过度的分层直接导致的后果就是开发效率低下！
Hibernate
优点：ORM 的领头羊，ORM 事实上的标准，功能完善，学习资料丰富
缺点：在效率上有些问题，加之含有许多的 hbm 配置文件强行与实体代码分隔。
Struts 1.x
优点：老牌 MVC 框架，MVC 事实上的标准
缺点：说实在的我感觉除了比 Servlet 少在 web.xml 中配置一些东西、自动封装 FormBean 之外，没感觉到有什么好处，这个框架最不好用的就是它的标签，除了 html 标签好用之外，其他的标签极其不好用，特别是 logic:iterator 远远没有 c:forEach 用起来舒服。
Struts 2.x/WebWork 没用过。
JBoss Seam
优点：
完全打破三层体系架构，借助于 JSF 采用两层结构，页面层和组件层，Seam 是按照业务逻辑来分层，而不是按照架构来分层。
Seam 的最低版本是在 JDK 1.5 之上设计的，使用了很多 JDK 1.5 的新特性，大量地使用 Annotation，这种方式完全可以取代复杂的配置文件。就算是其中的日志组件也是采用变参实现的，这样我们就不用在页面上写 if(log.isDebugEnabled()) 了。
采用严格 xml 格式的 xhtml JSF 页面，将 JSF 原本的配置分散到每个页面的 .page.xml 文件中，可以在里面写些：进入页面时需要执行的方法、有哪些参数需要传递的、页面如何导航等等。
Seam 拥有完善权限模型，权限不仅可以在页面中表现，也可以通过 Annotation 在方法上限制该方法的执行权限。
Seam/JSF 中的 Backing Bean 可以是普通的 Java Bean，也可以是 Session Bean，这样就可以让 Seam 工程不仅能运行在 EJB 容器中，也可以运行在 Servlet 容器中。
Seam 中扩充了 Servlet 中的请求范围，增加了 Conversation、Process，而不是 Servlet 中的 application, session, request, page 四种。最常用的是 Conversation 这表示一个业务逻辑的作用范围，比 Session 小，比 Request 大。这种扩充完全是为了一整步骤的业务逻辑而定制的。
想想看使用 Seam 可以使用 Seam Gen 或者是 JBoss Tools 的 Eclipse 插件产生某个表的增删改查分页功能，如果不涉及业务逻辑，而且使用默认的模板可以一行代码不用写，快速开发，诱人吧 ^_^
以 JBoss Seam 为蓝本，其作者 Gavin King 提交的 JSR 299 -- WebBeans (Java Contexts and Dependency Injection) 已经被 JCP 采用，作为 Java EE 6 中的一部分。
缺点：
学习难度相对于 SSH 大很多，学习资料相对较少，其中所使用的 JSF 不用说了，相对于 Hibernate，Seam 所使用的 JPA 也是需要一定阶段地学习才能灵活使用的。其中还有多如牛毛的 Annotation、双向注入、 WebBeans 等概念也是需要一定时间来掌握的。
Seam 中所使用的页面组件框架，比如 Ajax4JSF, RichFaces 等等也是需要一定时间来掌握的。
[/Quote]
JBoss Seam
对我很有吸引力
gao512008 2009-10-14
- 打赏
- 举报
[Quote=引用 3 楼 bao110908 的回复:]
我并不认为 Spring 有多好，极其繁多且扰乱思维的配置文件。另外，不管大小程序，都有事没事要你用 IoC 整个接口出来，感觉有点为了接口而接口。
[/Quote]
唯一感觉得好的 就是方便多人开发
其他，没感觉的好
我并不认为 Spring 有多好，极其繁多且扰乱思维的配置文件。另外，不管大小程序，都有事没事要你用 IoC 整个接口出来，感觉有点为了接口而接口。
[/Quote]
唯一感觉得好的 就是方便多人开发
其他，没感觉的好
火龙果被占用了 2009-10-14
- 打赏
- 举报
下面这些是原来在 http://topic.csdn.net/u/20090504/17/969c7340-ebbe-4b79-b579-2d4563bb6de7.html 这个帖子中的回复，有兴趣的话可以看一下。
下面是我对一些开源框架的观点：
Spring
优点：IoC、AOP 容器，集大成者，集众框架，可谓包罗万象，应有尽有，学习资料丰富
缺点：极其繁杂的配置文件，原来有个 Spring 的项目，配置文件就有 8000 多行，可以把人看晕掉，极其不喜欢！大事小事都得弄个接口，感觉是为了接口而接口，估计有好多人是先写类再写接口的吧？复杂的配置文件与过度的分层直接导致的后果就是开发效率低下！
Hibernate
优点：ORM 的领头羊，ORM 事实上的标准，功能完善，学习资料丰富
缺点：在效率上有些问题，加之含有许多的 hbm 配置文件强行与实体代码分隔。
Struts 1.x
优点：老牌 MVC 框架，MVC 事实上的标准
缺点：说实在的我感觉除了比 Servlet 少在 web.xml 中配置一些东西、自动封装 FormBean 之外，没感觉到有什么好处，这个框架最不好用的就是它的标签，除了 html 标签好用之外，其他的标签极其不好用，特别是 logic:iterator 远远没有 c:forEach 用起来舒服。
Struts 2.x/WebWork 没用过。
JBoss Seam
优点：
完全打破三层体系架构，借助于 JSF 采用两层结构，页面层和组件层，Seam 是按照业务逻辑来分层，而不是按照架构来分层。
Seam 的最低版本是在 JDK 1.5 之上设计的，使用了很多 JDK 1.5 的新特性，大量地使用 Annotation，这种方式完全可以取代复杂的配置文件。就算是其中的日志组件也是采用变参实现的，这样我们就不用在页面上写 if(log.isDebugEnabled()) 了。
采用严格 xml 格式的 xhtml JSF 页面，将 JSF 原本的配置分散到每个页面的 .page.xml 文件中，可以在里面写些：进入页面时需要执行的方法、有哪些参数需要传递的、页面如何导航等等。
Seam 拥有完善权限模型，权限不仅可以在页面中表现，也可以通过 Annotation 在方法上限制该方法的执行权限。
Seam/JSF 中的 Backing Bean 可以是普通的 Java Bean，也可以是 Session Bean，这样就可以让 Seam 工程不仅能运行在 EJB 容器中，也可以运行在 Servlet 容器中。
Seam 中扩充了 Servlet 中的请求范围，增加了 Conversation、Process，而不是 Servlet 中的 application, session, request, page 四种。最常用的是 Conversation 这表示一个业务逻辑的作用范围，比 Session 小，比 Request 大。这种扩充完全是为了一整步骤的业务逻辑而定制的。
想想看使用 Seam 可以使用 Seam Gen 或者是 JBoss Tools 的 Eclipse 插件产生某个表的增删改查分页功能，如果不涉及业务逻辑，而且使用默认的模板可以一行代码不用写，快速开发，诱人吧 ^_^
以 JBoss Seam 为蓝本，其作者 Gavin King 提交的 JSR 299 -- WebBeans (Java Contexts and Dependency Injection) 已经被 JCP 采用，作为 Java EE 6 中的一部分。
缺点：
学习难度相对于 SSH 大很多，学习资料相对较少，其中所使用的 JSF 不用说了，相对于 Hibernate，Seam 所使用的 JPA 也是需要一定阶段地学习才能灵活使用的。其中还有多如牛毛的 Annotation、双向注入、 WebBeans 等概念也是需要一定时间来掌握的。
Seam 中所使用的页面组件框架，比如 Ajax4JSF, RichFaces 等等也是需要一定时间来掌握的。
下面是我对一些开源框架的观点：
Spring
优点：IoC、AOP 容器，集大成者，集众框架，可谓包罗万象，应有尽有，学习资料丰富
缺点：极其繁杂的配置文件，原来有个 Spring 的项目，配置文件就有 8000 多行，可以把人看晕掉，极其不喜欢！大事小事都得弄个接口，感觉是为了接口而接口，估计有好多人是先写类再写接口的吧？复杂的配置文件与过度的分层直接导致的后果就是开发效率低下！
Hibernate
优点：ORM 的领头羊，ORM 事实上的标准，功能完善，学习资料丰富
缺点：在效率上有些问题，加之含有许多的 hbm 配置文件强行与实体代码分隔。
Struts 1.x
优点：老牌 MVC 框架，MVC 事实上的标准
缺点：说实在的我感觉除了比 Servlet 少在 web.xml 中配置一些东西、自动封装 FormBean 之外，没感觉到有什么好处，这个框架最不好用的就是它的标签，除了 html 标签好用之外，其他的标签极其不好用，特别是 logic:iterator 远远没有 c:forEach 用起来舒服。
Struts 2.x/WebWork 没用过。
JBoss Seam
优点：
完全打破三层体系架构，借助于 JSF 采用两层结构，页面层和组件层，Seam 是按照业务逻辑来分层，而不是按照架构来分层。
Seam 的最低版本是在 JDK 1.5 之上设计的，使用了很多 JDK 1.5 的新特性，大量地使用 Annotation，这种方式完全可以取代复杂的配置文件。就算是其中的日志组件也是采用变参实现的，这样我们就不用在页面上写 if(log.isDebugEnabled()) 了。
采用严格 xml 格式的 xhtml JSF 页面，将 JSF 原本的配置分散到每个页面的 .page.xml 文件中，可以在里面写些：进入页面时需要执行的方法、有哪些参数需要传递的、页面如何导航等等。
Seam 拥有完善权限模型，权限不仅可以在页面中表现，也可以通过 Annotation 在方法上限制该方法的执行权限。
Seam/JSF 中的 Backing Bean 可以是普通的 Java Bean，也可以是 Session Bean，这样就可以让 Seam 工程不仅能运行在 EJB 容器中，也可以运行在 Servlet 容器中。
Seam 中扩充了 Servlet 中的请求范围，增加了 Conversation、Process，而不是 Servlet 中的 application, session, request, page 四种。最常用的是 Conversation 这表示一个业务逻辑的作用范围，比 Session 小，比 Request 大。这种扩充完全是为了一整步骤的业务逻辑而定制的。
想想看使用 Seam 可以使用 Seam Gen 或者是 JBoss Tools 的 Eclipse 插件产生某个表的增删改查分页功能，如果不涉及业务逻辑，而且使用默认的模板可以一行代码不用写，快速开发，诱人吧 ^_^
以 JBoss Seam 为蓝本，其作者 Gavin King 提交的 JSR 299 -- WebBeans (Java Contexts and Dependency Injection) 已经被 JCP 采用，作为 Java EE 6 中的一部分。
缺点：
学习难度相对于 SSH 大很多，学习资料相对较少，其中所使用的 JSF 不用说了，相对于 Hibernate，Seam 所使用的 JPA 也是需要一定阶段地学习才能灵活使用的。其中还有多如牛毛的 Annotation、双向注入、 WebBeans 等概念也是需要一定时间来掌握的。
Seam 中所使用的页面组件框架，比如 Ajax4JSF, RichFaces 等等也是需要一定时间来掌握的。
liangjun19801210 2009-10-14
- 打赏
- 举报
[Quote=引用 36 楼 fan_niao 的回复:]
1、AOP-面向切面编程 对业务过程处理进行提现。
2、有自己的框架（虽然用起来，很少）
[/Quote]
看来大家还是比较认同AOP。
1、AOP-面向切面编程 对业务过程处理进行提现。
2、有自己的框架（虽然用起来，很少）
[/Quote]
看来大家还是比较认同AOP。
雪狼孤竹 2009-10-14
- 打赏
- 举报
Spring 风很大！
liangjun19801210 2009-10-14
- 打赏
- 举报
[Quote=引用 24 楼 kokobox 的回复:]
知道一个框架好在哪里最简单，去官网看看就知道了。
难在你是否知道这个框架哪里不好！！！ 这才能让你更好的去使用！！！！
[/Quote]
我是觉得 这个框架对我的帮助不是很大，没有象之前的MVC框架让我“为之一震”的感觉。
知道一个框架好在哪里最简单，去官网看看就知道了。
难在你是否知道这个框架哪里不好！！！ 这才能让你更好的去使用！！！！
[/Quote]
我是觉得 这个框架对我的帮助不是很大，没有象之前的MVC框架让我“为之一震”的感觉。
liangjun19801210 2009-10-14
- 打赏
- 举报
感谢fan578和bolink5 两位美女的回复。代码界美女不多啊。
liangjun19801210 2009-10-14
- 打赏
- 举报
[Quote=引用 19 楼 zhangjihao 的回复:]
如果你不用EJB做开发，建议首选Spring框架来做J2EE项目，这是目前工业级J2EE软件为数不多的解决方案中最出色的。它至少有如下优点：
1、分层解藕特性：不会让程序陷入软件泥潭
2、切面编程特性：最成功的应用是在控制数据库事务，程序不必关心是ORM或者你的连接是如何打开和关闭数据库连接的。你可以利用这种技术在庞大的项目中横着切一刀插入自己特色的技术需求，例如权限检查，敏感词、漏洞注入、挂马类威胁元素检查等等
3、封装了大部分J2EE应用：例如JavaMail，JMS，WebService、线程池、任务调度等等，这些注入后拿来就用，能节省60%以上代码量。
4、一个出色的子集——Spring MVC，它在早期版本中就支持Html上的form表单与后台Pojo绑定，即使复杂的数据类型(例如一个表单控件对应自己编写的一个类)，一个属性编辑器就可以搞定。2.5版本以后全面支持注解，也称@MVC，只要把基础的配置在xml文件里写好，以后几乎不用和xml文件打交道，它灵活得让人难以想像。后台多对一、一对多或多对多保存甚至修改，前台只需要一个form表单来接收数据就够了。 在Java社区里，Apache是比SpringSource知名度大，这也是程序员，尤其是中国的程序员没用Spring MVC的最大原因。但在Spring集成开发中，有这么一个强大的web层框架，何必还集成一套Struts？我认为SJ(Spring+JPA，可用Hibernate实现)要比SSH架构方式优雅得多，SJ架构足以解决庞大的J2EE应用。
5、还有安全框架、动态语言一大把的应用
......
尤其是刚在J2EE里编程的程序员，建议看重Spring框架，也许是其作者除了是计算机专业外，还是一位优秀的音乐博士，这种天份铸就了优雅程序的基础，写出来的代码就是不一样。
[/Quote]
感谢留言，写这么多，辛苦！
回复第一点：分层解耦特征，我还没搞清楚，等下查查。
二 ：AOP，认同，spring确实可以带来这方面的好处。
三 : 还没有对spring研究的这么深入，但是JavaMail，JMS，WebService、线程池,这些东西，应该是spring能集成进来的吧。如果不用spring，这些东西 我也可以随便组合着用。？
五 ：彻底的不了解。嘎嘎
如果你不用EJB做开发，建议首选Spring框架来做J2EE项目，这是目前工业级J2EE软件为数不多的解决方案中最出色的。它至少有如下优点：
1、分层解藕特性：不会让程序陷入软件泥潭
2、切面编程特性：最成功的应用是在控制数据库事务，程序不必关心是ORM或者你的连接是如何打开和关闭数据库连接的。你可以利用这种技术在庞大的项目中横着切一刀插入自己特色的技术需求，例如权限检查，敏感词、漏洞注入、挂马类威胁元素检查等等
3、封装了大部分J2EE应用：例如JavaMail，JMS，WebService、线程池、任务调度等等，这些注入后拿来就用，能节省60%以上代码量。
4、一个出色的子集——Spring MVC，它在早期版本中就支持Html上的form表单与后台Pojo绑定，即使复杂的数据类型(例如一个表单控件对应自己编写的一个类)，一个属性编辑器就可以搞定。2.5版本以后全面支持注解，也称@MVC，只要把基础的配置在xml文件里写好，以后几乎不用和xml文件打交道，它灵活得让人难以想像。后台多对一、一对多或多对多保存甚至修改，前台只需要一个form表单来接收数据就够了。 在Java社区里，Apache是比SpringSource知名度大，这也是程序员，尤其是中国的程序员没用Spring MVC的最大原因。但在Spring集成开发中，有这么一个强大的web层框架，何必还集成一套Struts？我认为SJ(Spring+JPA，可用Hibernate实现)要比SSH架构方式优雅得多，SJ架构足以解决庞大的J2EE应用。
5、还有安全框架、动态语言一大把的应用
......
尤其是刚在J2EE里编程的程序员，建议看重Spring框架，也许是其作者除了是计算机专业外，还是一位优秀的音乐博士，这种天份铸就了优雅程序的基础，写出来的代码就是不一样。
[/Quote]
感谢留言，写这么多，辛苦！
回复第一点：分层解耦特征，我还没搞清楚，等下查查。
二 ：AOP，认同，spring确实可以带来这方面的好处。
三 : 还没有对spring研究的这么深入，但是JavaMail，JMS，WebService、线程池,这些东西，应该是spring能集成进来的吧。如果不用spring，这些东西 我也可以随便组合着用。？
五 ：彻底的不了解。嘎嘎
凡鸟回归 2009-10-14
- 打赏
- 举报
1、AOP-面向切面编程 对业务过程处理进行提现。
2、有自己的框架（虽然用起来，很少）
2、有自己的框架（虽然用起来，很少）
麻烦的一笔 2009-10-14
- 打赏
- 举报
用了spring只会使开发周期更长，所以要从效率来看struts+hibernate的组合是最好的！
liangjun19801210 2009-10-14
- 打赏
- 举报
[Quote=引用 17 楼 adaikiss 的回复:]
以前一直在用SSH,最近在尝试不用SSH布署个项目看看
于是自己写hibernate的ORM,自己写spring的IOC/DI,自己写struts的转发控制,spring的AOP还没弄明白所以就暂时没用上,其实弄来弄去也就是MAP和反射.
个人觉得有现成的成熟的框架能用为什么不用?又方便,又能起到一定的规范作用(指MVC、IOC、OO、ORM规范),还能定制自己要的功能!
当然如果你喜欢,你依然可以为每个查询操作写SQL语句,依然可以把存储的东西看成是关系,而不是对象.
也许你更喜欢将程序依赖于具体的东西而不是抽象的类或方法.或者你觉得在web.xml中写上一大堆Servlet看起来更顺眼,更容易维护,你能更好地对各个Servlet进行分组,能更好地用拦截器、过滤器对它们进行插拔式地管理,那么请继续,Patrick Lightbody、Craig McClanahan、Rod Johoson、Gavin King都会理解你的！
并不是说只能用SSH，SSH只是一个代表，框架有很多，选择用或不用、用哪些都是个人依实际情况选择的！
[/Quote]
spring确实可以和一些框架集成，但不用spring，并不意味着我要重新制造轮子，比如mvc,OR/MAP。
（只是说出我的想法，没有冒犯的意思，忘见谅）
以前一直在用SSH,最近在尝试不用SSH布署个项目看看
于是自己写hibernate的ORM,自己写spring的IOC/DI,自己写struts的转发控制,spring的AOP还没弄明白所以就暂时没用上,其实弄来弄去也就是MAP和反射.
个人觉得有现成的成熟的框架能用为什么不用?又方便,又能起到一定的规范作用(指MVC、IOC、OO、ORM规范),还能定制自己要的功能!
当然如果你喜欢,你依然可以为每个查询操作写SQL语句,依然可以把存储的东西看成是关系,而不是对象.
也许你更喜欢将程序依赖于具体的东西而不是抽象的类或方法.或者你觉得在web.xml中写上一大堆Servlet看起来更顺眼,更容易维护,你能更好地对各个Servlet进行分组,能更好地用拦截器、过滤器对它们进行插拔式地管理,那么请继续,Patrick Lightbody、Craig McClanahan、Rod Johoson、Gavin King都会理解你的！
并不是说只能用SSH，SSH只是一个代表，框架有很多，选择用或不用、用哪些都是个人依实际情况选择的！
[/Quote]
spring确实可以和一些框架集成，但不用spring，并不意味着我要重新制造轮子，比如mvc,OR/MAP。
（只是说出我的想法，没有冒犯的意思，忘见谅）
liangjun19801210 2009-10-14
- 打赏
- 举报
[Quote=引用 16 楼 youjianbo_han_87 的回复:]
唉，我们这些没用过ejb的后辈是没法体会的，如果你用ejb做大型企业级开发做个1，2年，然后用spring做做看，就知道了。
实践才是检验真知的唯一方式。
[/Quote]
题外话：EJB其实没有网上说的那么恶魔，只是开始接触它时，经常被弄的比较晕，即使弄出一个可以运行的示例程序，也不知道真正的原理。
顺便做个广告：Head First EJB 绝对是一本值得看的书（看了之后，突然感悟，原来EJB就那么回事）
再推荐一本：Head First 设计模式。
唉，我们这些没用过ejb的后辈是没法体会的，如果你用ejb做大型企业级开发做个1，2年，然后用spring做做看，就知道了。
实践才是检验真知的唯一方式。
[/Quote]
题外话：EJB其实没有网上说的那么恶魔，只是开始接触它时，经常被弄的比较晕，即使弄出一个可以运行的示例程序，也不知道真正的原理。
顺便做个广告：Head First EJB 绝对是一本值得看的书（看了之后，突然感悟，原来EJB就那么回事）
再推荐一本：Head First 设计模式。
liangjun19801210 2009-10-14
- 打赏
- 举报
to 大王让我来巡山啊、热心的小强！、小鲁：AOP应该算是一种编程思想，用spring可以轻松做到，这应该是用spring的比较好的理由。
z812183667 2009-10-14
- 打赏
- 举报
其实，不管什么东西都有他的优点和缺点，例如你要是只是做一个简单的登录要用SSH框架纯粹是浪费，那spring也不好用了，但是你要是处理的逻辑比较复杂，就用把所有的对对象交给spring来管理就会比不用简单的多了！
这是我的个人意见，仅供参考！！！
这是我的个人意见，仅供参考！！！
不爱吃萝卜的兔子 2009-10-14
- 打赏
- 举报
spring在维护上确实有好处
liangjun19801210 2009-10-14
- 打赏
- 举报
[Quote=引用 12 楼 haojia0716 的回复:]
对于大项目来说用spring是不错的
通常对于一个项目 维护的开销(时间金钱人力物力等)是开发的开销的两倍 spring的好处就体现在维护上 包括重用性 扩展性等
至于小项目 还不一定用java
[/Quote]
恩。应该有这方面的好处，能控制做到面向接口编程，对维护上肯定有帮助。
但是如果在大项目运用，配置文件似乎就能把人给砸死。。。
如果一个系统有700以上的table,hibernate的配置，spring的配置。。。my god....
对于大项目来说用spring是不错的
通常对于一个项目 维护的开销(时间金钱人力物力等)是开发的开销的两倍 spring的好处就体现在维护上 包括重用性 扩展性等
至于小项目 还不一定用java
[/Quote]
恩。应该有这方面的好处，能控制做到面向接口编程，对维护上肯定有帮助。
但是如果在大项目运用，配置文件似乎就能把人给砸死。。。
如果一个系统有700以上的table,hibernate的配置，spring的配置。。。my god....
gerry313 2009-10-14
- 打赏
- 举报
路过
liangjun19801210 2009-10-14
- 打赏
- 举报
to ydcsh、portnet、才饮酒中水，又闻稻花香、a103176270、axe、andesen：握个手，谢谢帮顶！
liangjun19801210 2009-10-14
- 打赏
- 举报
[Quote=引用 5 楼 starc 的回复:]
有了Spring就不再为数据库连接池发仇了（Spring 对本人最大的用处），还有就是解藕合（很多时候解不解都无所谓）
[/Quote]
不知道是不是通过spring与hibernate 整合的方式处理你的持久层。
如果只是为了数据库的连接池问题，用spring似乎多余了哦。hibernate本身可以配置连接池，proxool 等东西也是非常不错的。
很欣赏"很多时候解不解都无所谓"这句话，解耦 是那些大师们追求的东西（当然我们也要尽量注意解耦）。
但感觉通过DI的方式解耦，其实就是把我们原来的工厂搬到配置文件里面了。不知道为什么spring 会拿这个来大肆宣传。
有了Spring就不再为数据库连接池发仇了（Spring 对本人最大的用处），还有就是解藕合（很多时候解不解都无所谓）
[/Quote]
不知道是不是通过spring与hibernate 整合的方式处理你的持久层。
如果只是为了数据库的连接池问题，用spring似乎多余了哦。hibernate本身可以配置连接池，proxool 等东西也是非常不错的。
很欣赏"很多时候解不解都无所谓"这句话，解耦 是那些大师们追求的东西（当然我们也要尽量注意解耦）。
但感觉通过DI的方式解耦，其实就是把我们原来的工厂搬到配置文件里面了。不知道为什么spring 会拿这个来大肆宣传。
加载更多回复（33）
