根据一个Spring程序所想到的用法

今天主要通过简单配置xml文档、编写底层java代码并通过Spring将二者进行连接的思想实现了一个很小的Spring基础代码，旨在了解基本的实现机理。

代码主要包括：
Action接口:
Action 接口定义了一个execute 方法，不同的Action 实现提供了各自的execute方法，以完成目标逻辑。

public interface Action {
public String execute(String str);
}

Action接口的两个实现UpperAction、LowerAction
(UpperAction将其message属性与输入字符串相连接，并返回其大写形式。
LowerAction将其message属性与输入字符串相连接，并返回其小写形式。)

public class UpperAction implements Action {
private String message;
public String getMessage() {
return message;
}
public void setMessage(String string) {
message = string;
}
public String execute(String str) {
return (getMessage() + str).toUpperCase();
}
}

Spring配置文件（bean.xml）
注:bean.xml配置文件应该与.project工程在同一目录下

< beans >
< description >Spring Quick Start </ description >
< bean id ="TheAction"
class ="net.xiaxin.spring.qs.UpperAction" >
< property name ="message" >
< value >HeLLo </ value >
</ property >
</ bean >
</ beans >

测试代码
利用Spring组件实现简单的IOC思想

public void testQuickStart() {
ApplicationContext ctx= new
FileSystemXmlApplicationContext( "bean.xml");
Action action = (Action) ctx.getBean( "TheAction");
System.out.println(action.execute( "Rod Johnson"));
}

基础代码&Spring组件&XML文件之间的关系

根据我画的图可以看出：
1． 我们的所有程序代码中（除测试代码之外），并没有出现Spring中的任何组件。
2． UpperAction和LowerAction的Message属性均由Spring通过读取配置文件（bean.xml）动
态设置。
3． 客户代码（这里就是我们的测试代码）仅仅面向接口编程，而无需知道实现类的具体名称。同时，
我们可以很简单的通过修改配置文件来切换具体的底层实现类。

而这些又对实际开发有和帮助呢
? 首先，我们的组件并不需要实现框架指定的接口，因此可以轻松的将组件从Spring中脱离，甚
至不需要任何修改（这在基于EJB框架实现的应用中是难以想象的）。
? 其次，组件间的依赖关系减少，极大改善了代码的可重用性。

Spring的依赖注入(DI)机制，可以在运行期为组件配置所需资源，而无需在编写组件代码时就加以指定，从而在相当程度上降低了组件之间的耦合

从这个例子看到，通过Spring组件，在运行期间将字符串“HeLLo”注入到Action实现类的Message属性中。



IoC，看了很多的Spring书籍，都说IoC是Spring的核心思想，所以想好好理解一下，按我理解的来看，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓“控制反转”的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。
依赖注入（Dependency Injection）是IoC的另一种称呼,可能这种称呼感觉起来会更加精准一些,亦即组件之间的依赖关系由容器在运行期间决定,
因此我认为依赖注入的目标并非是为web开发带来更多的功能,而是为了提升组件重用的概率,并为系统搭建一个灵活\可扩展的平台所作出的贡献,同时依赖注入机制意味着，组件得到重用的机会将会更多。(代码共享主义社会的实现将不远亦)


Spring的几个重要类及相应接口

BeanFactory
Bean Factory负责根据配置文件创建Bean实例，可以配置的项目有：
1． Bean属性值及依赖关系（对其他Bean的引用）
2． Bean创建模式（是否Singleton模式，即是否只针对指定类维持全局唯一的实例）
3． Bean初始化和销毁方法
4． Bean的依赖关系

ApplicationContext
ApplicationContext覆盖了BeanFactory的所有功能，并提供了更多的特性，所以一般开发都会使用ApplicationContext
构造ApplicationContext的两种种方法：
application context构造器通常使用字符串或字符串数组作为资源(比如组成context定义 的XML文件)的定位路径。

当这样的定位路径没有前缀时，指定的 Resource 类型会通过这个路径来被创建并被用来载入bean的定义，这都取决于你所指定的application context。

1、如果使用下面的代码来创建ClassPathXmlApplicationContext ：

ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");

――这个xml文件中的bean的定义会通过classpath载入并使用ClassPathResource。

2、利用FileSystemXmlApplicationContext
ApplicationContext ctx =
    new FileSystemXmlApplicationContext("conf/appContext.xml");
这种定义中，xml文件中的bean的定义会通过文件系统从相对于当前工作目录中被载入。

注意1：
请注意如果定位路径使用classpath前缀或标准的URL前缀，那它就会覆盖默认的Resource 类型。因此下面的FileSystemXmlApplicationContext...

ApplicationContext ctx =
    new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");

实际上会通过classpath载入其bean定义。然而他仍是个FileSystemXmlApplicationContext。如果后面它被当作ResourceLoader 来使用，那么任何没有使用前缀的路径依然会被当作一个文件系统路径。

注意2：
实际上如果的确需要使用绝对路径，那你最好就不要使用 FileSystemResource 或 FileSystemXmlApplicationContext来确定绝对路径。我们可以通过使用 file: URL前缀来强制


使用UrlResource。

// actual context type doesn't matter, the Resource will always be UrlResource
ctx.getResource("file:/some/resource/path/myTemplate.txt");

// 强迫FileSystemXmlApplicationContext 来加载通过UrlResource定义的文件
ApplicationContext ctx =
    new FileSystemXmlApplicationContext("file:/conf/context.xml");

(明天继续explorer...)

明日安排：
继续熟悉ApplicationContext
WebContext
Web 应用与MVC