[深入理解ORMapping.docxVIP

深入理解OR Mapping从工作流管理系统和信息共享平台的设计开发过程中，不断的摸索面向对象分析和面向对象设计的方法，因为面向对象程序设计更加接近人的思维活动，利用这种思想进行程序设计时，可以很大程度的提高编程能力，缩短软件开发周期，减少软件维护的开销。面向对象技术已经成为软件开发的一种趋势。通过工作流管理系统和信息共享平台的设计和实现，我们对面向对象的程序设计的认识也越来越深刻，逐渐过渡到以面向对象的思想为基准的分层、分布式程序设计开发方式。通过理论、实践、理论的步骤，不断总结学习的过程中，发现原来对OR－Mapping的认识是不正确的。首先概述以下原来软件设计的过程：首先从需求出发，分析用户需求，界定系统功能，然后做详细设计，详细设计阶段主要是拉通业务流程，根据业务流程，完成数据字典的设计，如果采用面向对象开发的方式，我们将会抽象出业务实体对象，并将他和关系型数据库的表和字段联系起来，进行映射，完成从具有关系型的表到对象的映射，这也就是我开始对OR－Mapping的理解，后来意识到这种认识是错误的，面向对象的开发过程也存在问题。面向对象的分析设计方法强调分析和设计全部采用面向对象的方法。从用户需求出发，分析面向对象的业务，在分析阶段应该构建出面向对象的分析模型，这些模型是概念模型，和任何数据库或者语言无关。不产生数据字典，而是概念层次的UML图。进入到设计阶段，UML近一步被细化，设计出类图和类接口。这个过程中并不考虑数据库的结构。当把类图和接口设计完毕后，根据设计的对象来生成相应的数据库结构。而不是上面提到的根据数据库结构建立对象，这个由根据“对象来生成相应的数据库结构”的过程其实正是我们要讨论的OR－Mapping的问题，对象关系的映射问题。下面的章节，将详细讨论OR－Mapping的相关问题，还讨论了面向对象的数据库设计的方式，以及自己对面向对象分析设计的一点感想。为什么我们要做OR－Mapping？如果我们采用面向对象的思想进行系统的分析设计，而数据库采用关系型数据库就会存在这个不容忽视的问题。面向对象设计和关系型数据库设计存在很大的不同。对象模型和关系模型两者之间“阻抗不匹配”。对象模型基于软件工程的一些原理，面向对象设计的理论包括封装、关联、聚合、继承、多态，而关系模型主要针对数据的存储，“阻抗不匹配”就成为了他们的主要矛盾。我们希望通过面向对象的设计方式来完成业务流程，这一点可以实现，但最终如何把对象保存下来，是必须考虑的。如果我们的存贮介质采用关系型数据库，那么怎样将对象保存到关系型数据库的时候，矛盾也就出现了。也是我们要做OR－Mapping的主要原因，架起对象和关系型数据库的桥梁。OR－Mapping主要解决对象层次的映射、对象关系的映射以及对象的持久化问题。OR－Mapping是面向对象分析设计的产物，也是分层设计要解决的问题之一。OR－Mapping会给程序设计带来那些好处呢？在面向对象的分层设计的系统体系中，上层的程序执行最终结果都是要操作数据库，而数据库是关系型，不是面向对象的，正是通过对象关系的映射，使我们实现了只对上层对象的操作实现对表的操作，感觉好象没有数据库的存在，上层只管面向对象编程就可以了。OR－Mapping的原则O-R Mapping通常的做法是将程序中的类映射到数据库的一个或多个表, 但是，由这种方式会带来一些问题。首先就是数据实体在数据库和程序中的表现方式不一样，对于一些涉及到多个表的“粗粒度对象”，一个实体类可能会引用到多个其它实体类，也就是说会在涉及到对象粒度的建模方面带来一些问题；其次在同数据库交互时，也涉及到一个转换的问题，如果一个对象涉及到对多个表的操作，问题就更大；最后，当系统做查询操作，需要返回多个对象时，因为涉及到转换的问题，效率就比较低下。上面提到的这些都是我们实际要考虑的问题，这里就涉及到做O-R Mapping的原则问题。我们做数据映射时依据一个什么样的标准，以什么原则为指导，那些因素是我们在映射的过程中必须考虑的，下面我将谈到这个问题。①、性能：对象映射到表时，性能将是最主要的考虑因素。对象映射到表的方式将会对数据库访问的次数有显著的影响。数据库访问通常是在磁盘上或其它外部媒介上执行，它们的访问时间数量级大约在毫秒级，而CPU的处理周期是在纳秒级。因此，较好的做法是浪费一些存储周期和内存空间，来提高慢速IO的性能。其中有一些做法是计算机可以自己做的，例如Cache、DMA方式等等，有一些则需要我们通过编程来手动处理，减少对数据库的访问次数，例如延迟读、为数据置标志位等等。　延迟读的核心思想是用到那些数据就读那些数据，比如一个人员对象，有个部门属性，人员和部门分别存放在不同的表中，在初始化人员这个对象时就没必要把部门这个属性一起初始化，当需要这个属性时