spring概念介绍及自己的一点感受

Spring 的核心是个轻量级
（Lightweight）的容器
（Container），它是实现IoC
（Inversion of Control）容器、非侵入性
（No intrusive）的框架，并提供AOP
（Aspect-oriented
programming）概念的实现方式，提供对持久层（Persistence）、事务（Transaction）的支持，提供MVC
Wexiele haojiu b 框架的实现，并对一些常用的企业服务API（Application
Interface）提供一致的模型封装，是一个全方位的应用程序框架（Application
framework），除此之外，对于现存的各种框架（Struts、JSF、Hibernate 等），Spring 也提供了与它们相整合的方案。

对于像我这样的对框架知识甚是缺乏的人来说，想要看懂上面的文字还需要对各个名词好好解释下。

术语:

1)轻量级-Lightweight

轻量级的形容是相对于一些重量级的容器（如EJB 容器）来说的，Spring 的核心包在文件容量上只有不到1MB 的大小，而使用Spring 核心包所需要的资源负担也是很小的，您甚至可以在小型设备中使用Spring 的核心包。

ps：java刚入门，对于EJB根本没有了解过，要看的东西好多。另外，一直比较疑惑这些所谓轻量级或者重量级是否没有一个统一的标准，记得说
Swing是个轻量级的gui包（完全使用自己虚拟机的资源，而不用系统资源，比如画笔等，不知道理解对不对），而这里的轻量级的概念的意思好像是指内容
少，开发包小。

2)非侵入性（No intrusive）

框架原来的用意是提供一个架构的实现，让开发人员可以在基于框架的基础上，快速地开发出遵循架构的所需的应用程序，然而有些框架一旦被使用，应用程序就与
框架发生了依赖，例如大量使用了框架的API，或直接继承API
的某些类型等，都会使应用程序组件与框架发生依赖，而无法从框架中独立出来，更别说当中的组件可以直接重用到另一个应用程序之中。

Spring 的目标之一是实现一个非侵入性（No
intrusive）框架，希望让应用程序几乎感受不到框架的存在，减低应用程序在框架移植时的负担，进一步增加应用程序组件的可重用性
（Reusability），简单地说，使用Spring 的话，应用程序中某些组件可以直接拿到另一个应用程序或框架之中直接使用。

ps：这个，对于我们现在使用的WebNMS平台，无疑是个很大的亮点（不知道如何实现）。公司说下一版本要移出这个平台，我现在都难以想象这个过程——或许我对这个平台不熟。

3)容器（Container）



Spring
提供容器功能，容器可以管理对象的生命周期、对象与对象之间的依赖关系，您可以使用一个配置文件（通常是XML），在上面定义好对象的名称、如何产生
（Prototype 方式或Singleton
方式）、哪个对象产生之后必须设定成为某个对象的属性等，在启动容器之后，所有的对象都可以直接取用，不用编写任何一行程序代码来产生对象，或是建立对象
与对象之间的依赖关系。

换个更直白点的说明方式：容器是一个Java 所编写的程序，原先必须自行编写程序以管理对象关系，现在容器都会自动帮您作好。

ps：看到这里，才发现一直厌恶的原来webnms也有这么一个闪亮点，在这个xml技术到处放光的时代，想想这个技术的出现有必然因素。不过
webnms似乎做的太多了，以至于要修改一个它没有预料到地方得修改它的原代码（亲身经历的就是修改主界面的toolbar）。这似乎也是一个提供易用
性和复杂度的权衡。

4)IoC（Inversion of Control）



Spring 最重要的核心概念是Inversion of Control，中文常译为“控制反转”，更具体的另一个名词是Dependency
Injection，中文常译为“依赖注入”；使用Spring，您不必自己在程序代码中维护对象的依赖关系，只需在配置文件中加以设定，Spring
核心容器会自动根据配置将依赖注入指定的对象，在下一个小节当中，还会详细介绍Inversion of Control 与Dependency
Injection 的概念。

ps：
一直关注的OO设计原则终于看到了——反转倒置原则，感觉这些原则无非也就是grasp的几个基本原则，这个著名的原则就是低耦合和针对接口编程两项原则
的结合。在我看过的书中就有《敏捷软件开发——原则、模式与实践》和《java与模式》里面有描述。感觉这类原则（或者说模式）不像GOF模式，后者在你
一遍一遍看书或者偶然的在代码中看到就能深入人心，但是这些模式应用及其广泛，很多可能你一直在用（自己的经验）。

比如：

单一职责原则：这个原则非常简单，简单的说就是让你的每个类只做自己份内的事，现实经常碰到的情况（以前自己也常如此），常常是非常吝啬类，当需要增加一项新的功能时，往往考虑放在哪个类里面，于是常常出现一些高耦合性，不利于日后维护。比如：现在有一个对象工厂，

ProcuctFactory{

public Product createProduct（int ProductType）{...}

}

当出现需要维护product列表需求的时候，不应该觉得ProductFactory控制着product的生产，就想当然的把维护方法加到Factory里面。

ProcuctFactory{

public Product createProduct（int ProductType）{...}

public List getProducts(){...}

public boolean tackleProducts(){...}

}

这就明显的破坏了这一原则，会让使用者匪夷所思。正确的做法就是专门成立一个售后服务系统，专门维护已创造的产品（软件中即产生新类来维护产品，它的职责就是维护，而工厂的职责就是生产）。——3分钟内想到的例子，或许没有说服力。

开放-关闭原则：即对修改封闭，对扩展开放，这句话很难理解（至少在差不多一年前，初次注意这句话时一直不明白，而且查了很多资料都是说得模棱两可，那时候同样让我困惑的一句话是：不要对实现，而应该对接口编程），具体就不展开了，网上说得很经典的文章很多。

......

另外，记得猴王问我，觉得我的模式学的怎么样，我说刚入门。他说他得到答案了，我不知道是什么意思，但这里先说点模式的东西。

记得去年这个时候刚接触模式，

首先碰到的一个问题是：模式算什么？语言级的惯用法吗？企业级的框架吗？软件工程吗？

我想很多刚接触模式的人都有这个问题，其实模式概念很广，从其的定义大家就可以了解到（随便找了个网络文章，里面有解释： http://www.javafan.net/article/20041123142039257.html
），
它渗透在各个方面，包括特定语言的语言级惯用法，企业级框架其实很多都是由各式各样的模式搭建而成，所以，如果某人说他很懂模式，那他不是特牛的人，就是
对模式的基本概念都不懂的菜鸟。我们日常所说的模式一般都指GOF模式（即1995年出版的由四人帮执笔的设计模式一书中提到的模式），一般情况下大家平
常讨论的也就是它，这个方面有基本经典的书：首推的当然是GOF原书，10年了，在亚马逊上仍然名列前茅。另外就是最近狂热的Head First
DP，还有一本模式精简，是经典的入门书。

但是模式绝非仅仅于此，它涵盖了各个方面，比如OO里面（当然GOF的也属于此类），就有著名的grasp设计模式，另外还有一些有名的OO原则（前面所列）也都应该归于此类。另外在网络里面有专门的设计模式，这方面的先河之作应该算是ACE，书籍为： http://www.dearbook.com.cn/book/12515
，《面向模式的软件体系结构 卷2:用于并发和网络化对象的模式》（卷一是讲系统模式和部分惯用法，今天一看卷三也有了，好像讲软件工程管理方面的模式），作者也凭此成为模式界的世界级大师。另外多线程方面也有模式，比如：JAVA多线程设计模式（ http://www.dearbook.com.cn/book/33881
），一个小日本写的，最近刚在看，很不错。此外J2EE也有模式......

所以，模式渗透各个方面，一般都把它统归于软件工程，另外也有归于特定领域。

另外一个问题是：该如何学？（针对GOF模式，因为大家一般都指它）

这个大家说法不一，有人说就看经典书，有人说多读代码，有人说就学习库（比如经典的ace库）。

我
的认为是（虽然我也很一般，但是算是走过艰辛的人，就说一些经验）：其一，你需要了解一些OO的基础知识，这里并不是指什么继承啊，多态啊等等，而是一些
OO的设计原则，就如GRASP，学了这个之后你才会在学习模式的时候知其然并知其所以然，因为GOF模式无非是这些基本原则的特定应用。其二，需要拥有
一本入门书，GOF的原著绝非属于此类，HFDP据说不错，精简是个人觉得最好的（这里bs借书看的，模式属于手头参考的，应该是案头必备一本）。
JAVA与模式很不错，不仅介绍基本设计原则，还讲模式在java中的应用。其三，就是自己写代码，如果没有可以应用的场所，就自己写例子代码。

另外的问题是：如何才算入门？

其
实我自己也不知道自己到底算不算入门了，但是可以肯定地是：如果你在写代码的时候还跟以前一模一样，那肯定没入门，如果你在设计代码时，会考虑一下如何才
让它容易维护和使用，那么说明你已经有这个意识了，如果你在读代码或技术书籍的时候，常常有：“奥，这里是某个模式的应用！”，那么说明你对模式已经比较
熟悉。如果你看到一段代码就想大刀阔斧修改（当然要知道如何修改且有充分的修改理由），那么说明你有些功力了，如果你BS现在很多流行的框架，觉得自己也
能写出更好的，那说明是高手了。——哎，又再扯蛋了！（我估计是属于有这个意识了的状态）。

另外，毛和我经常碰到的：就是不知道该如何动手的问题（即知道实现，但是不确定自己的设计是否健壮和完善）？ 我不知道这是不是书上常说的过度设计问题。有时候写代码也要自信，该如何就该如何。

5)AOP（Aspect-oriented programming）

Spring 最被人重视的另一方面是支持AOP（Aspect-oriented programming）的实现，然而AOP
框架只是Spring 支持的一个子框架，说Spring 框架是 AOP 框架并不是一个适当的描述，人们对于AOP 的关注反映至Spring
上，使得人们对于Spring 的关注集中在它的AOP 框架上，虽然有所误解，但也突显了Spring 的另一个令人关注的特色。

举个实际的例子来说明AOP 的功能之一，假设您有个日志（Logging）的需求，您可以无须修改任何一行程序代码，就可以将这个需求加入至原先的应用程序之中，而若您愿意，也可以在不修改任何程序的情况下，将这个日志的功能移除。

Spring 的IoC 容器功能与AOP 功能的实现是其重心所在，在Spring 下实现了持久层、MVC Web 框架以及各种企业服务的API
封装，它们的实现有些依重于Spring 的IoC 容器与AOP 功能，Spring 的这些子框架或封装的API
功能彼此可以独立，也可以结合其它的框架方案加以替代，Spring 希望提供one-stop shop 的框架整合方案。

ps：AOP可谓最近最热的一个技术之一，SOA就凭借AOP掀起千层浪。具体我也没有学习过。对于我们这些java的新手，在技术上投资（如果能这么说
得话），SOA（或者说AOP）是块不错的土地。因为J2EE的高手实在太多了，有句话说得好，不要拉着fashion的尾巴走，技术也是，当一种技术新
兴时（当然SOA被关注至今也快有5年左右了，虽然有现实的产品才在这两年），如果觉得它不错，就要勇于投资，用《程序员修炼之道》的作者说：10年前投
资于JAVA的程序员，现在都在引领java世界。不过现在的我总觉得基础还得增强。

6)持久层

Spring 提供对持久层的整合，如对JDBC 的使用加以封装与简化，提供事务（Transaction）管理功能，对于O/R Mapping 工具（Hibernate、iBATIS）的整合，Spring 也提供了解决的方案。

ps：当OO课上老师大讲特讲O/R Mapping技术的时候，我非常疑惑，为什么OO老师比讲模式还重的笔墨来讲解它？有这种想法的原因是不知道企业应用开发中数据库有多重要，而数据库的维护成本有多高，有空得学学Hibernate。

这里顺便写写我现在是如何对待技术知识的（因为包括牛在内感觉我简直是瞎扯，东看一点，西看一点，所以澄清一下）：

我的原则很简单，我是这样想的：如果突然间，需要由我来领导一个项目组（而这个项目组可能缺任何方面的人）来开发项目的时候，不应该出现束手无策的情况。所以，

0.首先,我会关注一些基础知识,至少知道一些基本的网络,操作系统,安全,算法方面的知识.这些除了原先在大学学过之外没有特别关注过,所以非常薄弱.
但是现在一直没有经历,而且找工作ms最需要这方面(这次惨了).所以,一直想买本高程的书看看,并不是想要考证,而是想整理一下自己的基础知识.

1.我会关注OO，因为这关系到软件的维护和作为程序员自身修养的提高；

2.我会关注一门语言，要不断地熟悉它，在每个方面都要有所涉猎,比如:最基本的gui,thread,util.其中,如果有客户交互部分,应该给予特
别重视(几乎每个程序设计大赛都在这方面设立一个奖项_比如趋势百万大赛),要关注界面设计(有些人天生不重视界面设计,注定要失败,这方面很多是从现在
公司感受到的——第一次发现一个界面可以花这么多人/日来搞定，很受启发.)，另外学一门比较小巧的语言。

3.我会努力关心我所关心得语言的相关框架和开源项目和工具，作为一个项目负责人的时候，我想最重要的就是知道什么工具能够帮助你，什么工具最适合你，比
如拿java来举例，我应该至少要知道怎么用ant来配置项目环境，如何用cvs来管理版本，如何用Bugzilla来管理项目bug，如何用
XPlanner或者Teamwork来管理项目进度,如何用wiki来共享团队信息和交互；

4.我会关注测试，从最原始的（贴近程序员）单元测试，以及到集成测试，系统测试等一系列过程，以及白盒黑盒等等测试方法，以及如何测试计划和书写测试用例，以及回归测试这一不容忽视的环节，这就是我一直想好好做一回测试工作的原因；

5.我会关注项目过程管理，迭代开发是非常经典的，xp的原则是非常迷人的，虽然我没有在任何地方使用过，但是相信只要好好关注，使用它们还是没有问题。
而我现在在团队中感觉到的是有名无实。比如，迭代开发的实施中，明确指出需求不用全部都做完再开始迭代（这也不可能），一般开始迭代时只有20%的需求是
明确的，但是同时又需要注意的一点是，对于就要开始的当次迭代，需求必须是明确的（这是很多人的误区），但现在却出现迭代中需求变化很大的情况，这能叫迭
代开发吗？这只能说是瀑布开发的重蹈，把一个开发过程机械拆分成N个相对独立的片段，然后标上版本号，得到只是N个瀑布开发！这可能有效果吗？另外，xp
倡导的原则里面有一个是“可持续的速度”，同时敏捷宣言里面也有必须遵循的原则：敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长
期的、恒定的开发速度。我想加班总不应该算是其中之一吧。有人会反驳，那是程序员自己没有完成分配的任务，这是应该的（牛，在这里我告诉你，这不是程序员
的原因，这是管理者的原因。因为程序员技术水平的参此不齐是肯定存在的,作为一个管理者,你完全有义务了解到这一点,进而给他稍微宽松的任务以使整个团队
的进度一致,否则他就不是一个称职的管理者或经理）——这其实也是结对编程的好处。而习惯性的加班的后果只有我们对项目开发的厌倦（更可笑的是，明明只有
一半成员的任务没有完成，却整个项目组陪着加班）,久而久之项目组就会失去魅力.

6.我会想要关注一个方向:总觉得老是做东来西往的项目没有出路,带来的只会让你的知识比较广泛,而在每个特定的领域你算不上专家.所以一定要选择一个自
己准备献身一生的方向,记得有文章提到过,说,如果你进入某个行业的某一特定领域,你会成为这方面的专家,无疑,我们公司有好多人都是如此,但我不知道他
们意识到这点没有.至于我的方向,进入实验室之前一直以为是网络,但是现在又有些动摇.又觉得企业信息管理不错(因为我的金融学学位证书快生锈了,总不能
白学吧,白学了也要对得起交得6k的钱啊),但是这方面又有它的特殊性(往往不在于软件好坏,而在于实施水平,以及公司管理层得态度,所以单靠程序员得一
己之力很难完成).这是我的一个盲点.

7)Web 框架

Spring 也提供MVC Web 框架的解决方案，使用Spring Web 框架的好处是可以善用IoC 与AOP 的功能，您甚至可以轻松地替换使用不同的View 层技术，例如使用JSP、结合Tiles、使用PDF 作为展现给使用者的画面技术。

也可以将自己所熟悉的Web 框架与 Spring 整合，例如Struts、JSF 等，都可以与Spring 整合，而适用于当前所进行的应用程序。

ps:这点非常诱人,记得微软打击其他软件厂商得方法常常是捆绑销售,而很狠得一点是不支持与对手软件得交互共享(比如一些保存信息,例,rss浏览器的
频道列表)，所以其他对手想要跟ms竞争，基本的一点就是兼容。这一点在以后做软件中也是切记的，人家不一定要支持你，你一定要支持人家。怪不得这是
spring的一个亮点。

一直不了解Spring,Structs等等框架,心里一直想,学好语言和oo后肯定非常容易上手,导致的结果是到现在还没有准备去上手.什么时候有空真得关注一下.ms现在做项目没有不用这些流行框架得.靠白手起家自己写框架ms还嫩了一点.

8)其它企业服务的封装

对于一些服务，例如JNDI、Mail、任务计划（Scheduling）、远程（Remoting）等，Spring 不直接提供实现，而是采取抽象层方式对这些服务进行封装，让这些服务在使用时可以有一致的使用模型，并且在使用上更为简化。

ps：看到这些，发现自己java太薄弱了，或许根本算不上入门！：（

哎，本来是在rss浏览器上看到一个林信良（良葛格）的专栏的一篇spring的文章，想一直对这个概念都很困惑，值得了解一下，于是下了 http://www.dearbook.com.cn/Book/108341
里
面的样章的第一章看（里面ps之外的东西都是这本书里面的，ms这本书很多人推荐），后来想要记录下这章里面的部分东西，以后也可以回味，又觉得光抄不写
感触不好意思，最后花了3个小时，faint！就当好久没有写技术文章了的一点补偿吧。不过也有部分的牢骚，其中的见解或许根本就是一个门外汉的瞎扯，就
要找工作了，茫然啊！