Spring【1】

  入门01－简介Spring

Spring是轻量级的J2EE应用程式框架。

Spring的核心是个轻量级容器（container），实现了Ioc（Inversion  of  Control）模式的容器，Spring的目标是实现一个全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间彼此可以独立，也可以使用其它的框架方案加以代替，Spring希望提供one－stop shop的框架整合方案。

Spring不会特别去提出一些子框架来与先有的OpenSource框架竞争，除非它觉得所提出的框架够新够好，例如Spring有自己的MVC框架方案，因为它觉得现有的MVC方案有很多可以改进的地方，但是它不强迫您使用它提供的方案，您可以选用您所希望的框架来取代其子框架，例如您仍可以在Spring中整合您的Struts框架。

Spring的核心概念是IoC，IoC的抽象概念是“依赖关系转移”，像是“高层模组不应该依赖低层模组，而是模组必须依赖抽象”是IoC一种表现，“实现必须以来抽象，而不是抽象以来实现”也是IoC的一种表现，“应用程式不应依赖于容器，而是容器服务于应用程式”也是IoC的一种表现。

Spring的核心即是个IoC/DI的容器，它可以帮助程式设计人员完成组建（类别们）之间的依赖关系注入（连接），使得组建（类别们）之间的依赖达到最小，进而提高组建的重用性，Spring是个低侵入性的框架，Spring中的组建并不会意识到它正置身于Spring中，这使得组建可以轻易的从框架中脱离，而几乎不用人和修改，反过来说，组建也可以简单的方式加入至框架中，使得组建甚至框架整合变得容易。

Spring最为人重视的另一方面是支援AOP（Aspect－Oriented Programming），然而AOP框架只是Spring支援一个子框架，说Spring框架是AOP框架并不是一件适当的描述，人们对于新奇的AOP关注映射至Spring上，使得人们对于Spring的关注集中在它的AOP框架上，虽然有所误解，但也突出了Spring的另一个令人关注的特色。

Spring也提供MVC Web框架的解决方案，但您也可以将自己所熟悉的MVC Web框架与Spring结合，像是Struts、WebWork等等，都可以与Spring整合而成为适用于自己的解决方案。

Spring也提供其它方面的整合，像是持久层的整合如JDBC、O/R Mapping工具（Hibernate、iBATIS）、事务处理等等，Spring作了对多方面整合的努力，故说Spring是个全方位的应用程式框架。

入门02－控制反转IoC

IoC全名Inversion Of Control，如果中文硬要翻译过来的话，就是“控制反转”。初看IoC，从字面上不容易了解其义，我觉得要了解IoC，要先从Dependency Inversion开始了解，也就是依赖关系的反转。

简单的说，在模组设计时，高层的抽象模组通常是与业务相关的模组，它应该具有重用性，而不依赖于低层的实作模组，例如如果低层模组原先是软碟存取模式，而高层模组是个存档备份的需求，如果高层模组直接调用低层模组的方法，则就对其产生了依赖关系。

举个例子，例如下面这个程式：

＃include <floppy.h> .. .. .. void save(){   .. ..   saveToFloppy() } }

由于save()程式依赖于saveToFloop()，如果今天要更换低层的存储模式为Usb碟，则这个程式没有办法重用，必须加以修改才行，低层模组的更动造成了高层模组也必须跟着更动，这不是一个好的设计程式，我们希望模组都依赖于模组的抽象，这样才可以重用高层的业务设计。

如果以物件导向的方式来设计，依赖反转（Dependency Inversion）的解释变为程式不应依赖于实作，而是依赖于抽象，实作必须依赖于抽象。我们来看看下面这个Java程式。

public  class BusinessObject{   private FloppyWriter writer = new FloppyWriter();   .. .. ..   public void save(){ .. .. .. writer.saveToFloppy();   } }

在这个程式中BusinessObject的存档依赖于实际的FloppyWriter，如果今天我们想要将存档改为存至Usb碟，我们必须修改或继承BusinessObject进行扩展，而无法直接使用BusinessObject。如果透过介质的宣告，可以改进一情况，例如：

public interface IdeviceWriter{   public void saveToDevice(); }   public class BusinessObject{   private IdeviceWriter writer;   public void setDeviceWriter(IdevicWriter writer){     this.writer = writer;   }     public void save(){   .. ..   writer.saveToDevice();   } }

这样一来，BusinessObject就是可重用的，如果今天我有存储至Floppy或Usb碟的需求，我们只要操作IdeviceWriter即可，而不用修改BusinessObject；

 

Public class FloppyWriter implement IdeviceWriter{   Public void saveToDevice(){   .. .. 实际存储至Floppy的代码 } }   public class UsbDiskWriter implement IdeviceWriter{   public void saveToDevice(){   .. ..实际存储至UsbDisk的代码   } }

从这个角度来看，Dependency Inversion的意思是程序不依赖于操作，而是程序与操作都依赖于抽象。

IoC的Control是控制的意思，其实其背后也是一种依赖关系的转移，如果A依赖B，其意思是B拥有控制权，我们要转移这种关系，所以依赖关系的转移即是控制关系的转移，藉由控制关系的转移我们可以获得元件的可重用性，在上面的Java程序中，整个控制权从实际的FloppyWriter转移至抽象的IdeviceWriter介质上，使得BusinessObject，FloppyWriter，UsbDiskWriter这几个实现依赖于抽象的IdeviceWriter介面、

从容器的角度，程序的业务逻辑部分应该是可以重用的，不应受到所使用的框架或容器的影响，因为我们可能转移整个业务逻辑至其他框架或容器，如果业务逻辑依赖于容器，则转移至其他的框架或容器时就会发生困难。

IoC在容器的角度，可以用这么一句好莱坞的名言来代表“Don’t call me ,I will Call you”。用程序术语来说的话就是“必要想容器要求您所需要的资源，容器会自动将这些资源给您”。IoC要求的时容器不侵入应用程序本身，应用程序本身提供好介质，容器可以透过这些介面将所需的资源注入至程序中，应用程序不向容器主动要资源，故而不会依赖容器的元件，应用程序本身不会意识到正被容器使用，可以随时从容器中脱离而不用作任何修改，而这个特性正是一些业务逻辑中间件最需要的。

注：
    1、不知道本书是否为翻译版本，感觉不是很通顺，如果哪位知道原稿告诉我一下地址，十分感谢
    2、在举例中我还是不理解为什么这样的话就不需要改动BusinessObject了呢，改动后起码调用哪个对象部分
还是需要修改的啊？哪位看到的话可以解答一下，再次感谢。