数据库对象关系映射是目前非常火热的数据库访问技术。这又是一门“伟大"
的技术,实在有点博大精深了。有兴趣的话,可以自行搜索一下。
Mdtypes只是提供了一个Freebasic版的数据库对象关系映射的基本雏形。但它简单实用,虽然它无法象Entity Frame,或java的ORM那么牛逼哄哄,不过你也不用深陷伟大技术的伟大泥潭的苦恼。
对于经常使用vba的人来说,如果不使用recordset,那么数据库离你大概有十万八千里远,因为如果没有recordset,那么很多人根本不知道如何使用数据库。接下来的数据库对象关系映射,可能是另一个全新的方式(其实是新瓶装旧酒),这个冲击有点大。
接下来是我的粗浅的认识,可能会有很多错误,甚至理解偏差了,以后随着越来越深入的了解,可以慢慢改正:
1、数据库对象的映射:
一个数据库就是一个对象。数据库中有很多表,所有的表构成tables。tables就是一个集合。也有很多存储过程、很多视图、关系,这些都会构成集合。
一个表本身包含很多行记录。所有的行记录也是一个集合。一行记录(有很多列,每个都有列名),一行记录就构成了一个字典(或map),
其中列名就是key,列值就是value,表现为key=value这样的形式。所以一张表,实际上是一个List表+map的复合体(所谓的二维表)。
一张表中有很多列,所有的列本身也是一个集合,每一个列(字段名)有很多属性,如数据类型等,一个字段名的所有属性描述也构成了一个Map。
list和map都是对象,所以数据库里的对象,就这样映射到编程语言中的collection和map对象来。
2、数据库数据类型的映射:每一种数据库都有自己的数据类型。而每一种语言也有自己的数据类型,所以需要进行映射。
3、表与表之间关系的映射:这是一个非常蛋疼的话题。因为mdTypes中的持久化,还在发展中,所以这里就不扯。
由于目前mdTypes的持久化,特别是数据库持久化还是基本雏形,所以它的优缺点很明显,而且大部分的缺点是ORM本身就有的
缺点:
1、数据类型的对应:FB的数据类型如何与数据库的数据类型进行快速简便地映射,这本身是一个问题,虽然绝大部分的数据类型可以进行一一对应,但它始终是一个问题
2、colleciton必须有两个构造函数,一个是空的constructor,一个是带有参数的constructor。而FB的构造、解构函数是无法继承。也就是说这代码只能不厌其烦
地进行复制。同样的两个operator cast()和=也是无法避免。
3、目前还无法避免必须对数据库表设计的深入了解。虽然对于小项目,这没什么,但始终是一个大问题。
4、每次查询都得定义一次map的结构,并进行数据类型转换,这个工作量不小。(或许会有更简便的方法?)