java模式_DAO模式.docx

DAO设计模式DAO(DataAccessObject)模式实际上是两个模式的组合，即DataAccessor模式和ActiveDomainObject模式，其中DataAccessor模式实现了数据访问和业务逻辑的分离，而ActiveDomainObject模式，其中DataAccessor模式实现了数据访问和业务逻辑的分离，而ActiveDomainObject模式实现了业务数据的对象化封装，一般我们将这两个模式组合使用，因此，考虑到这些因素，这里将其作为同一个主题加以讨论。如图展示了DAO模式的实现层次。DAO模式通过对业务层提供数据抽象层接口，实现了以下目标：1.数据存储逻辑的分离通过对数据访问逻辑进行抽象，为上层机构提供抽象化的数据访问接口。业务层无需关心具体的select,insert,update操作，这样，一方面避免了业务代码中混杂JDBC调用语句，使得业务落实实现更加清晰，另一方面，由于数据访问几口语数据访问实现分离，也使得开发人员的专业划分成为可能。某些精通数据库操作技术的开发人员可以根据接口提供数据库访问的最优化实现，而精通业务的开发人员则可以抛开数据曾德繁琐细节，专注于业务逻辑编码。2.数据访问底层实现的分离DAO模式通过将数据访问计划分为抽象曾和实现曾，从而分离了数据使用和数据访问的地称实现细节。这意味着业务层与数据访问的底层细节无关，也就是说，我们可以在保持上层机构不变得情况下，通过切换底层实现来修改数据访问的具体机制，常见的一个例子就是，我们可以通过仅仅替换数据访问曾实现，将我们的系统部署在不同的数据库平台之上。3.资源管理和调度的分离在数据库操作中，资源的管理和调度是一个非常值得关注的主题。大多数系统的性能瓶颈往往并非集中于业务逻辑处理本身。在系统涉及的各种资源调度过程中，往往存在着最大的性能黑洞，而数据库作为业务系统中最重要的系统资源，自然也成为关注的焦点。DAO模式将数据访问逻辑从业务逻辑中脱离开来，使得在数据访问层实现统一的资源调度成为可能，通过数据库连接池以及各种缓存机制(StatementCache,DataCache等，缓存的使用是高性能系统实现的一个关键所在)的配合使用，往往可以保持上层系统不变的情况下，大幅度提升系统性能。4．数据抽象在直接基于JDBC调用的代码中，程序员面对的数据往往是原始的RecordSet数据集，诚然这样的数据集可以提供足够的信息，但对于业务逻辑开发过程而言，如此琐碎和缺乏寓意的字段型数据实在令人厌倦。DAO模式通过对底层数据的封装，为业务曾提供一个面向对象的接口，使得业务逻辑开发员可以面向业务中的实体进行编码。通过引入DAO模式，业务逻辑更加清晰，且富于形象性和描述性，这将为日后的维护带来极大的便利。试想，在业务曾通过Customer.getName方法获得客户姓名，相对于直接通过SQL语句访问数据库表并从ResultSet中获得某个字符型字段而言，哪种方式更加易于业务逻辑的形象化和简洁化？空洞地谈些理论固然没有什么价值，我们需要看到的是通过对应用设计模式之后，我们的代码到底有怎样的改观，进而才能对设计带来的优劣有所感悟。下面让我们来看看代码：PublicBigDecimalcalcAmount(StringcustomerID,BigDecimalamount){//根据客户ID获得客户记录Customercustomer=CustomerDAO.getCustomer(customerID);//根据客户登记获得打折规则Promotionpromotion=PromotionDAO.getPromotion(customer.getLevel());//累积客户总消费额，并保存累计结果Customer.setSumAmount(customer.getSumAmount().add(amount));CustomerDAO.save(customer);//返回打折后金额Returnamount.multiply(promotion.getRatio());}这样的代码相信已经足够明晰，即使对于缺乏数据库技术基础的读者也可以轻松阅读。从上面这段代码中，我们可以看到，通过DAO模式对各个数据库对象进行封装，我们对业务层屏蔽了数据库访问的底层实现，业务曾仅包含与本领域相关的逻辑对象和算法，这样对于业务逻辑开发人员(以及日后专注于业务逻辑的代码阅读者)而言，面对的是一个简洁明快的逻辑实现结构。业务层的开发和维护将变得更加简单。DAO模式中，数据库访问层实现被隐藏到DataAccessor中，前面说过，DAO模式实际上是两个模式的组合，即DataAccessor和DomainObject模式。何谓DataAccessor?即将数据访问的实现机制加以封装，与数据