DAO模式实际是2个模式的组合，即Data Accessor和Domain Object模式
    Data Accessor即将数据访问的实现机制加以封装，与数据的使用代码相分离，从外部来看，Data Accessor提供了黒盒式的数据存取接口。Domain Object则提供了对所有面向领域内对象的封装。
   
    DAO模式实现了业务逻辑与数据逻辑的分离。对于专项开发而言，这样的分离设计差不多已经可以实现开发过程中业务层面和数据层面的相对独立，并且在实现复杂性与结构清晰性上达到较好的平衡。
    对于一个产品化的业务系统而言，软件产品往往需要在不同客户环境下即时部署。由于java良好的跨平台支持，我们在操作系统之间大可以轻易迁移，但在另外一个层面，数据库层，却仍然面临着平台迁移的窘境。针对不同的数据库，我们可以实现针对不同类型数据库的Data Accessor，并根据客户实际部署环境，通过类文件的静态替换来实现。这样将大大增加部署和维护工作的难度和复杂性。我们应该将此类因素带来的变动屏蔽在系统之外。

    Factory模式在这里起到连接接口和实现的桥梁作用，通过Factory模式，我们可以根据具体需要加载相应的实现，并将此实现作为所对应接口的一个实例提供给业务层使用：
   
    为了提高性能，避免每次调用都读取配置文件所引起的大量磁盘操作，采用了HashMap作为DAO缓存实现示例：
  
  

  
    业务层通过接口调用底层实现，具体的DAO实现类不会出现在我们的业务代码中。而具体实现类在配置文件中加以配置，之后DAOFactory.getDAO方法通过读取配置文件获得当前我们期望使用的实现类的类名，在通过Java Class动态加载机制加载后返回。

    通过接口与实现的分离，并结合DAOFactory动态加载实现类，我们实现了底层访问实现的参数化配置功能。
    无论有多好的理由，新的设计必须避免影响业务逻辑代码的可读性。没有哪个物业公司能说服你在自己的房屋中增加一条穿堂而过的管道，而理由是为了实施更好的供暖设计，我们的软件也一样。

    现在有越来越多的关键应用和大型应用是基于J2EE 来创建的，像银行系统和帐单系统这些关键应用要求有很高的可用性，而Google 和Yahoo 这样的大型应用就需要很好的可扩展性。在如今这个联系越来越紧密的世界，高可用性和良好的可扩展性的重要性日益突出。例如在1999 年6 月份，eBay 的服务停止了22 个小时，导致大约230 万的拍卖被中断，eBay 的股票也随之下降
了9.2 个百分点。
       J2EE 集群就是一种能够提供高可用性、可扩展性以及容错性的流行技术。但是由于在J2EE 规范中没有对集群做出规范，各个J2EE 厂商就使用不同的方式来实现集群，这样就给系统架构师和开发人员带来了很多麻烦。下面就是常见的一些问题：
•     为什么带有集群支持的商业J2EE 服务器产品如此昂贵？（是无集群支持产品的10 倍）
•     为什么在单机环境下创建的应用在集群环境中无法正常运行？
•     为什么我的应用在集群环境下运行的非常慢，但是在单机模式下却没有这个问题？
•     为什么我的集群应用在向其他厂商的服务器迁移时会失败？
要理解为什么会有这些限制，最好的方法就是研究它的实现，以揭开J2EE 集群的面纱。

  基本术语
       在我们开始讨论对于集群不同的实现之前，我想，了解一下集群技术的一些基本概念还是很有意义的。希望本章不单单是告诉你这些概念和设计问题，也同时能够为你勾勒一下不同J2EE集群实现的框架以便于理解。
可扩展性
       在一些大型系统中，很难提前预知最终用户的数量以及他们的使用行为，所以，可扩展性就是指一个系统能够快速适应用户数量的增加。提高服务器处理能力的最直 接的方法就是增加硬件资源，例如CPU、内存或者硬盘等。集群是解决这个问题的另外一种方式，它使得一组服务器共同分担繁重的任务，但对于最终用户来说就 像一台服务器。

高可用性
     通过向单机添加硬件来扩展系统能力的方案并不可靠，因为单一的服务器存在一个单点故障。像银行系统、帐单系统这样的关键应用甚至连一分钟的停机都不能容 许，它们需要在任何时间都是可用的，并且要能够保证响应速度。集群技术就可以满足这个要求，它通过加入冗余服务器使得在一个服务器出错而停止服务的时候， 这些冗余的服务器可以继续服务。

负载均衡
     负载均衡是集群的另外一个关键技术，它通过将请求分发到不同的服务器来达到高可用性和高效的处理能力。负载均衡器可以是一个servlet，也可以是一个 插件（例如Linux 上的ipchains），甚至还可以是一个比较昂贵的内嵌了SSL 支持的硬件产品。为了能够分发请求，负载均衡器还需要做一些重要的工作，例如使用“会话粘滞”技术以确保来自同一个用户的请求会被转发到同一个服务器；使 用“健康检查”（或者“心跳监听”）技术来防止将请求转发到一个失败的服务器；有时候负载均衡器还将参与“失败转移”的工作。

容错
       高可用的数据并不必是严格正确的数据。在J2EE 集群中，当一个服务器实例失败了，在集群中冗余的服务器就可以处理新到的请求，这样就保证了服务依然可用。但是在服务器失败的那一刻，正在被处理的请求就 可能无法得到正确的数据。那么，带有容错功能的集群就可以确保请求所得到的数据是正确的，哪怕是服务器端出现了错误。
       这个是怎么实现的呢？确实需要我们去进行思考！

失败转移
       在集群中，失败转移是实现容错的一个关键技术。当最初的节点失败之后，在集群中选择另外一个节点来完成处理。失败转移到其他节点可以通过编码实现，也可以由平台自动实现。

幂等方法
       如果一个方法使用同样的参数进行多次调用所得到的结果都一样，也就是说对于该方法的调用次数不影响系统，那么这个方法就叫做“幂等方法”。例如 “getUsername()”就是一个幂等方法，而“deleteFile()”就不是幂等的。在讨论 HTTP 会话失败转移和EJB 的失败转移时，幂等方法是一个很重要的概念

重/轻量：其实是使用难易程度，从根本上说，重/轻量应该和可伸缩性不矛盾的，特别是EJB 3.0推出以后，这个问题应该得到比较好的解决。
　　 但是，在目前情况下，编写一个JavaBeans要比编写一个EJB容易多，那么，是重/轻量还是可伸缩性应该成为系统架构的主要依据呢？ 在这个问题背后，还隐藏了目前在开源领域两个架构技术选择：
　　1. 重量：基于JBoss/EJB的完整J2EE系统架构 （具有可伸缩性，目前不易于学习）
　　2. 轻量：基于Tomcat的Struts+Hibernate/Spring+Hibernate （目前无太大可伸缩性，但是易于学习使用）

因为轻量解决方案易于学习新技术，容易使用，选中率比较高。但是让人产生对系统的可伸缩性担忧。鉴于这种情况，我认为有必要强调一下可伸缩性的重要性，切不能因为要跟进新的设计思想和技术，而盲目地采用一个无可伸缩性的设计方案。

其实，"轻量"应该是一个中性词，但是因为大量新的设计思想比较容易通过轻量方案获得成型软件，如（Spring/Naning/Hibernate）等，逐渐的"轻量"好像变成了一个褒义词。 如果从可伸缩性的标准看，轻量还可能是一个贬义词，轻量意味着丧失重量系统中的分布式网络计算的设计考量，那么可伸缩性就要打问号。

从这次JavaOne大会以及从长远来看，随着EJB 3.0中间件轻量化、SOA架构理念普及，轻量/重量的区别已经模糊，如果还是以轻量/重量作为架构选择的标准，甚至标榜自己的系统，无疑是不明智的。

可伸缩性应该依然是实用企业系统架构的主选，可伸缩性是站在软件公司的客户企业立场，为这些客户企业考虑的，但是他们经常因为被认为是外行，挡在了软件系统架构选择的门外。

可伸缩性:所谓可伸缩性，是指在小型规模单台服务器情况下，应用系统可以良好运转，系统的访问量或功能增加后，整个系统只需通过增加服务器硬件就可以实现性能扩展，无需修改太多软件。对于可伸缩性平台（如JBoss）来说，理论上，没有最大负载或最多在线人数这样的概念。

    持久：英文即Persistence,简单来讲，也就是把数据保存到可掉电式存储设备中供之后使用。数据持久化往往意味着将内存中的数据保存到磁盘上加以固化，而持久化的实现过程则大多通过各种关系型数据库来完成。
    持久层：也就是在系统逻辑层面上，专注于实现数据持久化的一个相对独立的领域。
    所谓的持久层，其判定标准
    1、如果表示层发生变化，需要从JSP迁移到Java WebStart Client，我们的数据库代码是否需要重新编译。
    2、如果业务逻辑层发生了变化，那么数据持久化代码是否需要重新编译？
    3、如果地秤数据库持久化机制发生了改变，那么，系统中的非持久化部分代码是否需要重新编译？
   
    何谓耦合：就是事务之间的相互关联关系
    何谓解耦：即采用一些手段降低关联的紧密程度。
    我们需要的是一个粒度适中的耦合关系，而并非完全意义上的松耦合。
   
    软件系统的研发过程中，贯穿了技术层面和业务层面的代码实现过程。程序逻辑必须结合业务领域内相应的数据和系统资源，反映出特定的业务逻辑。对于一个业务系统而言，系统研发的目的是为特定业务提供支持，业务逻辑往往是系统实现的核心。此时，将业务逻辑与数据访问逻辑相分离尤为重要。

    在业务逻辑的实现过程中，我们应该避免业务逻辑代码中混杂数据访问代码，而同样，数据访问代码中，也应该避免出现业务逻辑代码。

    通过良好的设计将逻辑结构与物理结构相分离。这里所谓的物理结构并非传统意义上的硬件设备，而是我们所无法控制的系统层面，如底层数据库接口。

    目标只有一个，底层实现变动的情况下，尽量避免对上层结构产生影响。一个设计良好的持久层实现，即便从oracle切换到mysql数据库，也不会引起大范围的代码变更。

    DAO(Data Access Object)模式，DAO模式实际上是2个模式的组合，即Data Accessor模式和Active Domain Object模式，其中Data Accessor模式实现了数据访问和业务逻辑的分离，而Active Domain Object模式实现了业务数据的对象化封装，一般我们将这2个模式组合使用。
    DAO模式通过对业务层提供数据抽象层接口，实现了以下目标：
    1、数据存储逻辑的分离
    通过对数据访问逻辑进行抽象，为上层结构提供抽象化的数据访问接口。业务层无需关心具体的select,insert,update操作，这样，一方面避免了业务代码中混杂JDBC调用语句，使得业务逻辑实现更加清晰，另一方面，由于数据访问接口与数据访问实现相分离，也使得开发人员的专业划分成为可能。
    2、数据访问底层实现的分离
    DAO模式通过将数据访问划分为抽象层和实现层，从而分离了数据使用和数据访问的底层实现细节。这意味着业务层与数据访问的底层细节无关，也就是说，我们可以在保持上层结构不变的情况下，通过切换底层实现来修改数据访问的具体机制。
    3、资源管理和调度的分离
    在数据库操作中，资源的管理和调度是一个非常值得关注的主题。大多数系统的性能瓶颈往往并非集中在业务逻辑处理本身。DAO模式将数据访问逻辑从业务逻辑中脱离出来，使得在数据访问层实现统一的资源调度成为可能，通过数据库连接池以及各种缓存机制的配合使用，往往可以在保持上层系统不变的情况下，大幅度提升系统性能。
    4、数据抽象
    DAO模式通过对底层数据的封装，为业务层提供一个面向对象的接口，使得业务逻辑开发人员可以面向业务中的实体进行编码。通过引入DAO模式，业务逻辑更加清晰，且富裕形象性和描述性。

    终于又开始写博客了，当初不知什么原因把自己从前写的技术文章(虽然都是书本上的知识)全都删除了，前端时间的工作差点使自己崩溃。10.1前和从前的朋友去吃了顿饭，这顿饭使我受益匪浅，最近一直在思考换工作，他说即时换了工作也就是钱多一点，你自己根本就不知道要什么，确实，这几年工作我真的不知道要什么(也许有的人和我有一样的感觉，做我们这行的)，换工作的频率不算高，也不算低，每一年换一次，不知道自己的下一个目标在哪里，为了钱而换工作么，还是为了一个好的工作环境，工作只是暂时的，最主要的是自己知道想要什么，我现在也不知道自己想要什么，但是目前的目标是确定了，找个好点的工作，慢慢想吧。
    已经有一个多月没看书了，早上9点上班，晚上10点下班，下班之后，洗把脸就睡觉，不知道自己怎么这么累，说不上来，可能是胡思乱想。经过10.1的休息，感觉自己有了点明确的目标，最起码知道自己要干什么，虽然不知道自己想要什么，
先写到这里。