关于数据访问模式(一)—— 数据访问模式的重要性
2005-07-21 18:23 FantasySoft 阅读(4524) 评论(0) 编辑 收藏 举报
在企业级应用当中,数据是企业资源的重要组成部分。应用程序的开发也是围绕数据的组织和存储、数据的访问、数据的处理、数据的表示进行的。由于这几个方面为整个应用程序系统提供了服务(Service),因此我们可以把这几个方面统称为数据服务(不知道用这样的名词去概括是否恰当)。
我们从企业应用程序常用的三层或者多层结构可以看出,每一层都无法离开数据,每一层都拥有一个独有的关注点。正是由于数据在企业级应用程序中举足轻重的作
用,各种各样专注于数据服务的技术和工具层出不穷,像.NET世界中的Data Access Control,像J2EE世界中的EJB等等。
纵观数据服务的各个层面,数据的组织和存储自然是数据库的天职了;而数据的处理则是跟专门的业务逻辑紧密联系的,开发可重用的组件有非常大的难度,而且复用的范围会受制于行业之间的巨大差异性。那么,复用的范围就缩小到了数据的访问以及数据的表示方面,O/R Mapping(主要是J2EE方面)的框架满天飞以及Web Control(主要是.NET方面)开发如火如荼恰好说明了这一点。
偶对Web Control的开发知之甚少,对于O/R Mapping也是略知一二(两边都不到岸,呵呵),本不该在此妄言什么。不过,结合以前以及现在项目的经验,对数据访问模式方面有了些思考,故记录于 此,以期有更多的反馈和指正。
我们先来看一个较为完整的团队的组成结构:Project Manager,System Architect,System Analyst,Database Administrator,Database Designer, Tester,Advanced Programmer,Programmer。对于以上的团队组成,我想对于有项目经验的朋友来说,一定不会陌生了,但是你或许会觉得有点迷惑,讲述数据访问模式方面的思考,为什么要先从团队结构入手呢?或许你还记得EJB核心技术所涉及的六种角色吧,毕竟技术的选择以及使用的情况都会直接影响到团队的组成。还记得在上个项目当中,我只是一个小小的程序员,由于公司在O/R Maping方面使用了Entity Bean并且在应用程序框架中实现了一个相当简陋的Data Accessor(说它简陋,是因为Data Accessor仅仅是对JDBC进行了很简单的封装,除了Connection不用再花心思之外,SQL照写不误),那么涉及到数据库的查询操作就用Data Accessor,其他需要修改数据表的操作则一律使用Entity Bean提供的方法,甚至一些复杂事务的处理亦是如此。在这样背景下,团队中仅由两个人身兼Database Administrator和Database Designer两职。然而事实上,他们手头上的工作仅限于Administration的工作——建立并维护用于开发的数据表,虽然人少,也能胜任。随着项目开发的深入,过度使用Entity Bean,过度依赖应用服务器而造成的性能问题逐渐显露。于是System Architect向Project Manager提出需要充分利用数据库服务器的能力。那么,如何去调整应用服务器和数据库服务器的负载比例呢?策略就是将复杂的事务处理装到存储过程中。好了,这下子DBA开始忙活了,两个人天天加班都没有办法跟上进度,于是除了我这个小小的程序员之外,还有很多同事也可以开始写存储过程了,一时间,团队中的Database Designer增加了许多许多,无法工作、难以维护的存储过程也相应出现了许多,毕竟我们并不是真正的Database Designer。讲述这个故事,无非是想强调数据访问模式本身的重要性。忽视了数据访问,对其各个方面考虑不够,将会对项目的开发造成极大的影响。
接下来,我们再来看看使用O/R Mapping框架的必要性。首先当然是降低了开发难度了,毕竟你可以在绝大部分时间里面逃避SQL带来的烦恼;接着就是更好的分工合作了,Database Designer可以专注于增加O/R Mapping框架的功能使其更加适合系统的要求。这些都是大的方面了,我们用放大镜看得仔细一些。O/R Mapping框架提供了对象与数据库表的映射。这样的映射关系并不是局限于表中的一行纪录对应一个对象,而有着更加广和深的内容:对象的标识,实现聚合关系,实现继承关系等。有了这样完整的映射关系,我们就不再需要面对艰深晦涩的SQL,而是通过操作对象的方式来操作数据库。对于这方面,我原本还想说一点东西,但是看了Teddy兄的post:O/R Mapping中对象关系映射解决方案汇总之后,我想我也没有必要再班门弄斧了。除了实现了完善的对象与关系映射之外,使用O/R Mapping框架还使得整个应用程序拥有统一的数据访问方式,事实上,统一与规范在企业级应用当中是相当重要的。
PS:在看《数据访问模式》一书的时候,想到了与数据访问有关的很多东西,有点支离破碎,希望各位多多批评了。
纵观数据服务的各个层面,数据的组织和存储自然是数据库的天职了;而数据的处理则是跟专门的业务逻辑紧密联系的,开发可重用的组件有非常大的难度,而且复用的范围会受制于行业之间的巨大差异性。那么,复用的范围就缩小到了数据的访问以及数据的表示方面,O/R Mapping(主要是J2EE方面)的框架满天飞以及Web Control(主要是.NET方面)开发如火如荼恰好说明了这一点。
偶对Web Control的开发知之甚少,对于O/R Mapping也是略知一二(两边都不到岸,呵呵),本不该在此妄言什么。不过,结合以前以及现在项目的经验,对数据访问模式方面有了些思考,故记录于 此,以期有更多的反馈和指正。
我们先来看一个较为完整的团队的组成结构:Project Manager,System Architect,System Analyst,Database Administrator,Database Designer, Tester,Advanced Programmer,Programmer。对于以上的团队组成,我想对于有项目经验的朋友来说,一定不会陌生了,但是你或许会觉得有点迷惑,讲述数据访问模式方面的思考,为什么要先从团队结构入手呢?或许你还记得EJB核心技术所涉及的六种角色吧,毕竟技术的选择以及使用的情况都会直接影响到团队的组成。还记得在上个项目当中,我只是一个小小的程序员,由于公司在O/R Maping方面使用了Entity Bean并且在应用程序框架中实现了一个相当简陋的Data Accessor(说它简陋,是因为Data Accessor仅仅是对JDBC进行了很简单的封装,除了Connection不用再花心思之外,SQL照写不误),那么涉及到数据库的查询操作就用Data Accessor,其他需要修改数据表的操作则一律使用Entity Bean提供的方法,甚至一些复杂事务的处理亦是如此。在这样背景下,团队中仅由两个人身兼Database Administrator和Database Designer两职。然而事实上,他们手头上的工作仅限于Administration的工作——建立并维护用于开发的数据表,虽然人少,也能胜任。随着项目开发的深入,过度使用Entity Bean,过度依赖应用服务器而造成的性能问题逐渐显露。于是System Architect向Project Manager提出需要充分利用数据库服务器的能力。那么,如何去调整应用服务器和数据库服务器的负载比例呢?策略就是将复杂的事务处理装到存储过程中。好了,这下子DBA开始忙活了,两个人天天加班都没有办法跟上进度,于是除了我这个小小的程序员之外,还有很多同事也可以开始写存储过程了,一时间,团队中的Database Designer增加了许多许多,无法工作、难以维护的存储过程也相应出现了许多,毕竟我们并不是真正的Database Designer。讲述这个故事,无非是想强调数据访问模式本身的重要性。忽视了数据访问,对其各个方面考虑不够,将会对项目的开发造成极大的影响。
接下来,我们再来看看使用O/R Mapping框架的必要性。首先当然是降低了开发难度了,毕竟你可以在绝大部分时间里面逃避SQL带来的烦恼;接着就是更好的分工合作了,Database Designer可以专注于增加O/R Mapping框架的功能使其更加适合系统的要求。这些都是大的方面了,我们用放大镜看得仔细一些。O/R Mapping框架提供了对象与数据库表的映射。这样的映射关系并不是局限于表中的一行纪录对应一个对象,而有着更加广和深的内容:对象的标识,实现聚合关系,实现继承关系等。有了这样完整的映射关系,我们就不再需要面对艰深晦涩的SQL,而是通过操作对象的方式来操作数据库。对于这方面,我原本还想说一点东西,但是看了Teddy兄的post:O/R Mapping中对象关系映射解决方案汇总之后,我想我也没有必要再班门弄斧了。除了实现了完善的对象与关系映射之外,使用O/R Mapping框架还使得整个应用程序拥有统一的数据访问方式,事实上,统一与规范在企业级应用当中是相当重要的。
PS:在看《数据访问模式》一书的时候,想到了与数据访问有关的很多东西,有点支离破碎,希望各位多多批评了。