Spring带来了什么？OOD学而无用

ps: OOD扫盲http://www.iteye.com/topic/1129283#2388708
----------------------------------------------------------------------
正文：

2年前曾发过一个贴子被评为新手：
http://www.iteye.com/topic/865387

终于有机会使用spring了，也用了一年了，再谈谈现在的感想，是否还会评为新手呢？
目前我接触到的spring功能包括：

IOC 构建分层关系：
具体指 action->service->dao 架构。我参与的项目都采用接口类型注入，这里还包括了spring的声明式事务的使用。

spring mvc。

spring aop

spring提供的功能糖（仿效语法糖的叫法），比如对hibernate blob clob类型的封装，对javamail的封装

spring aecgi

以下分类论述：
一、Spring的IOC的作用
  通过ioc，spring为web应用，提供了标准的软件结构定义，对于模块级的对象的访问，提供了统一的控制手段。换句话说，就是提供了web软件的架构模式，不管什么web软件，不必在自行设计架构，用spring的就行了。
  spring提供的架构方式，起到了规范化模块访问的作用，且支持声明式事务。
  这里有必要说明一下，我认为ioc应该采用接口类型注入，而不是类。原因是软件的结构清楚。这里的接口起到了类型隔离的作用，接口是纯粹的功能抽象，依赖于接口要比依赖于类单纯（接口更有用的使用方式是概念抽象）。另外，spring的aop在使用接口时用的是java的proxy技术，而不是cglib技术，我更愿意用java原生技术。(声明式事务会使用spring aop)

二、Spring mvc
  强大的mvc框架，使用方式多种多样，优其是spring 3的mvc，支持annotation的使用，使得Spring mvc易于使用。

三、Spring aop
  使用spring aop 可以完成一些原来难以实现的功能，比如：数据库事务失败后的重试（这种情况通常发生在数据库出现deadlock时）

四、Spring功能糖。
  我只用过两个见上文，很有用。

五、安全架框
  省时省力的完成对资源的访问控制。

Spring + mvc + orm 带来了什么呢？
总体上来看就是让程序员不必再费心思去找类，和决定类的职责分配，而这正是OOD的技能。软件的编写就是按照惯例把业务逻缉表达出来（当然这也有很多技巧，主要集中在库表设计，逻缉表达，性能调优上）
使用面象对象语言，而不需要OOD技能，实际上是降低了软件开发的难度。我身边的3年开发经验的人，对OOD基本上没概念，但软件开发作的也还可以。

这或者是好事吧。用不着OOD，自然就不必研究设计模式这些高深的玩意了，所以从事web开发的人，不断升级的结果就变成了业务专家，而对OO还是不甚了了。不过，当这样的程序员脱离了现有的框架，将寸步难行。

然而，中国还有哪些公司在作创造性的OOD开发呢？

ps: spring的异常处理思想也值得一提。

有些人，有了OO之后，就所有的东西都要 用到抽象，继承。
好像不这样就不是OO了。

其实，过度进行抽象集成反而是麻烦。

改基类导致全部都改，有好的可能，也有坏的可能。
关键在于业务逻辑的需求。

反正我用spring，很多bean就是直接一个类，而不是用接口+类的方式。

是，乱用OO的确有害。我想不同类型的软件对OOD的需要是不一样的。

我说的需要用 接口+类 形式的是指 service 和 dao，这些需要用IOC注入的类。
如果你也指这样的类，你说的用法也可以，我的建议有一部份是从审美的角度出发的。

我更懒,连service层都不要了,只留一个DAO层,业务逻辑写在pojo里面

spring带来了便利，但不代表你不需要思考，spring也没有说不需要你思考。

这个……我是看具体情况的。
一般来说DAO是数据访问层。
Service是业务逻辑层。
事务聚合，应该是业务逻辑层。
简单操作的话，加Service有点多余。
但是，复杂的话，还是有必要。
关键看上层怎么调用。

业务逻辑写pojo有好有坏，主要事务处理会比较复杂。

我是很多console程序用spring粘合，比较好修改。

千万不要以为有了Spring这些框架就不需要面向对象思想了。Java本身是面向对象的，只要你用Java编程就离不开面向对象。
很多人SSH也用了，各种封装也不少。但是代码一看，全是意大利面条不说，Dao里面干网页的活，action里面干数据库的活的很多。
Spring只是减少了你的重复劳动和一些基础设施的搭建。但是项目架构、业务建模还得你自己来。

面象对象的思想可以很深入，也需要一些难以掌握的技能，比如：职责分配、设计模式、软件设计建模（UML）等。用ssh的人是不必深入学习这些内容的。所以很多人做项目的流程是这样：
设计界面-》设计库表-》编码实现
不需要单独的OOD过程。

你说的软件实现不合理的情况，只要在公司有针对性的进行培训和代码复查即可解决。不需要深入学习OOD技能。

对于应用ssh软件的web项目，我认为没什么架构可言，软件结构是现成的。

业务建模是在分析阶段做的事，我这里说的是OOD。

不学习这个，只能当填空员了。公司如果都是这种程序员，那么没人可以培训和代码复查。
有了SSH就可以无视架构？这等于是从别人那里随便找了个打地基的方案，看也不看就用了。至于对方这个方案可以建几层楼，你需要几层楼根本没考虑。如果恰好碰上差不多的，就凑合了。如果对方只能盖平房的地基你来盖了3层楼，那就等着变危房吧。
业务建模贯穿整个开发始终，软件开发不是瀑布。

还是新手，鉴定完毕