不同数据库是否就意味着需要provider设计模式?

在.NET下, Provider设计模式得到风行, 本文将讨论数据库系统意义下的provider设计模式应用和实现要点.

大多数文章都将Provider设计模式的优点归结为屏蔽数据库系统的差异, 而且具体的,是屏蔽数据库系统引擎的差异; 这种理解不能说错,但是过于浅显; 如果仅仅屏蔽数据库系统引擎的差异, 隔离业务层和数据的话, 直接用ADO实现业务层需要的接口, 实现不了需求吗? 为什么还要编写大量的代码去实现Provider模式? 要增加一层的效率开销而引入Provider模式?而且客观地说, 当数据查询需求变动时, Provider代码变动时,也不够所谓的敏捷.

一个模式的应用总有它的实际需求做为驱动, 否则就可能被认为是"过度设计". 那为什么.NET还使用Provider呢?

这是因为,不仅仅是数据库系统引擎和接口的差异, 千千万万的网站的数据库表格是五花八门, 各个字段的名称不同,数据类型不同, 这时ADO层已经无论如何也做不到数据访问层的差异性屏蔽. 而且, 这些表格可能还被别的系统所使用, 考虑到数据的同步, 当迁移到新处理系统时不能指望客户将原有表格数据导入到新定义的数据表格中, 所以这时, 只能采用Provider模式来屏蔽这种差异性, 增加上层业务逻辑的复用性, 这才是引入Provider模式的真正需求和动力.

引入Provider模式后, 在实现时(非.NET平台, 如VC6下)最好参考以下两点:

结合可扩展性需求, 仅仅实现一个业务层需要的数据操作的一个最小集合;

对于大批量的记录集的遍历最好做上遍历接口, 结合Adapter为表示层提供数据, 表示层的DataGrid只维持仅仅当前显示的数据, 否则, 对于系统内存的开销和界面的响应速度都是个大问题.