Java,Spring,Hibernate,ibatis

在我们的系统设计过程中，一般都会采用分层设计的思想，即把一个系统划分为WEB层（主要是对Struts的应用）
业务层（Manager接口的应用）和持久层（DAO接口的应用）。这样的设计思想可以很好的业务流程控制，数据持久化
操作加以分离，从而提高了系统的扩展性，使系统的耦合度大大的降低！

1、关于耦合度。
所谓耦合度，按照本人的理解也就是指程序之间的关联程度。例如A类的运行必须由B类来支持，也就是说A类为了完成
一定的功能必须调用B类，那么A和B之间就存在了一定的关联，在程序设计中我们把这种关系叫做耦合。而在传统的软件
设计中降低程序之间耦合度是一个很重要思想。基于这种思想原则，我们在WEB系统设计中把数据库的访问操作（持久化）
和系统的业务流程控制中分离出来，这样就可以极大的降低了系统的耦合度，提高了程序的可移植性。例如把我们原本运行
在基于MySql数据系统的程序移植到Oracle数据库下。如果把数据库访问操作全部代码写到业务流程控制中（如在Struts的Action
中直接使用JDBC访问数据库）那么我们移植后的修改工作将会十分复杂，并且苦难特别大，尤其当我们在多个模块中采用了上述的
方式，那么这样的工作是多么的令人厌烦和恐惧啊。如果我们把数据库访问的操作放到一个专门的类中去完成，而在我们的WEB前台
流程控制中只是简单的调用这个类的方法，那么当我们的系统需要移植时候我们就可以简单的修改一下数据访问操作层的代码即可。
这样一方面另我们的工作大大的简化，另一方面使我们的代码更加优雅！

2，关于持久层
持久层是一个很大概念，并不是能够用三言两语就可以解释的很透彻的概念。针对我们上面的例子，我们所设计的那个专门用来访问
底层数据库系统的类就可以简单认为它是持久层上的一个类。它的主要任务就是把系统内的数据根据需要存储到数据库系统中，从而使得
数据可以持久的存储到数据库中从而实现数据的持久化过程。总而言之，持久层中的类主要是用来访问底层数据库系统，并允许其他程序
调用自己，从而实现对数据库的增，删，改，查的相关操作。总之持久层中的类大多都是工具类，主要作用是用来被别人调用的！

3、接口的应用
在实际的项目过程中，我们经常要进行面向接口编程，当然这种思想比较复杂，个人体会是面向接口编程一个比较突出的特点是利用接口
我们可以极大的提高程序的灵活度和可扩展性。首先接口定义了一套规则，一套与外部程序进行通信的规则，在WEB开发中的Servlet就极大
的发挥了接口的特性。针对上面提到的用例中，为了更好的在系统中进行分层，我们设计多个DAO接口，比如在一个电子商务系统中，既有用户注册登陆模块，又具
有产品查询等相关模块，而每一个模块都几乎不可避免的要对数据库进行相关的操作，如果只用一个DAO类来实现所有的这些功能是不可能的，
因此我们需要设计多个DAO接口。而每一个接口的实现类可以有多个，这样做的好处在于当我们需要对系统进行升级的时候，我们只需要在业务层改变相关的
传入的实现类即可（比如DAO的实现类可以有利用JDBC技术的来实现的，也有利用Hibernet的实现类，还有利用ibatis的），而在我们设计业务实现代码的过程
中可以充分的利用接口的特性来构造我们的代码，我们在业务层中只需关心我们调用的是否是一个DAO类（或Manager类）而不需要关心我们所接受的DAO类到底是
什么类型的，这样就很好的体现了面向对象思想中的多态的特性展示。从而提高了程序的灵活度和可扩展性。

4，关于Manager类的一些看法。
有人会问：既然DAO的设计已经实现了把分层设计的思想，那么为什么还要设计一个Manager类呢，Manager类的功能到底是什么？我个人的理解是，在
我们的系统中，业务逻辑控制层可以分为前台和后台两个层面，前台程序（比如Struts中的Action类）最好只负责与WEB相关的逻辑控制，它的主要
主要是面对用户的，用来对用户相关操作进行响应，而对于后台程序（比如利用Log4j技术来写入系统日志等）主要是针对开发人员的，我们可以利用
后台程序运行的结果来获取相关信息，这一层面属于后台业务层面。这样我们设计了Manager类，利用它来调用DAO类从而间接的对数据库进行访问，并且
实现了后台的业务控制。而在应用中我们最好也按照设计DAO类的思想来利用接口设计我们的Manager类，从而细化我们我的系统，提高程序的灵活性。

5，Factory类的设计思想。
既然我们的WEB层在运行过程中要调用Manager类和DAO类来实现对数据库系统的访问，那么当我们对系统进行升级和扩展后，那么我们不可避免的要对WEB层的
代码进行改造，这看起来似乎很简单，但当我们的系统毅然庞大时，即使很小的一些改动也是让人畏惧的，并且很有可能引发系统问题。在这样的需求下
我们设计出一个Factory类实现对Manager的“组装”。而在WEB层的调用中直接利用Factory类来获得Manager类来进行操作。Factory类的思想精髓在于利用反射机制
得到相关的类，并把所得到的类进行组装后返回给WEB层，而我们的需要反射进来的类的名字只需写在一个配置文件中即可。这样我们就可以实现不修改源代码，只修改
配置文件即可实现对系统的改变（关于Factory类的具体代码，可以参考Spring的ClassPathXmlApplicationContext的源代码，或者向传智播客的张孝翔老师请教，同时
我们在自行设计Factory时尽量的要把此类做为单例模式，把相关的方法设计成静态的方法从而节省内存空间。

6，Spring的Factory.
Spring是一个功能极其强大的框架，而它的核心类就是一个工厂类，利用它我们可以简化开发人员对工厂类设计。所谓框架，就是一个实现了某个功能的工具系统，
当然它只是一个半成品，我们可以手动的对它进行添加来实现我们的功能（比如Strust就是一个很好的实现了MVC模式的框加，而不严格的说TOMCAT也可以看作是一个
框加）。Spring提供了众多的工厂类，而它们都是ApplicationContext接口的实现类。只是这些工厂类所读取的文件只是XML文件。因此我们利用Spring的工厂类，关键是
对XML文件的配置。

7，Ibatis的简介。
为了实现数据的持久化操作，我们的应用程序必须与底层数据库系统进行交互，一个比较古老但”万金油“的办法是利用JDBC技术（Spring也提供JdbcTemplate来简化我们的
工作），而在面向对象的思想中，我们面对的都是数据都是一个一个的对象，而数据库内存储的是一张张的数据表，当我们访问数据库时需要把一个程序中的一个个的对象
转化成数据库可识别的数据，或者把从数据库中得到的数据封状成一个个的对象，并把这些对象返回给调用程序。而Hibernet,ibates等框架正好提供了这样的操作，可以把
对象到数据库的转化通过框架自动完成，从而避免了在程序中手动转化，而这种技术我们统称为ORM（Object Relation Mapping)技术。Hibernet是一个全自动的框架，它的功能
异常强大，而Ibatis是一种半自动的ORM技术，但它却能完成一些特殊的功能。Ibatis的核心类是SqlMapClient类，它通过对配置文件（sql-map-config.xml)的读取来完成对数据的
操作，在我们的DAO中只需要调用SqlMapClient相关方法即可完成相关操作，而在JDBC技术中需要书写的Sql语句只需要在Ibatis可识别的XML文件中书写即可，从而实现了把SQL语句从
JAVA源代码中分离的效果。
---------------------------------->来源于网络,服务于网络。