数据库粘合层--基于protobuffer
2013-03-05 14:17 yu_yu 阅读(479) 评论(0) 编辑 收藏 举报背景:
最近在工作中,受到大量数据库操作的折磨。由于采用拼接字符串的方式来进行数据库操作,带来了每个数据库操作业务都需要提供一个接口,导致同一张表的操作需要一堆堆接口。比如表person_t有3个字段(age、name、sex),如果对age和sex做update,需要一个接口,如果对age的update那又需要一个接口,对name的update还需要一个字段。这种接口会根据业务不断衍生出来,会造成接口大爆炸和拼接字符串出错而带来的额外高昂的成本。在我不堪折磨的时候想到了利用protobuf来解决此问题,proto_db横空出世。
作用:
类似于SAOP技术,基于protobuf。用于数据库数据与C++对象数据之间的序列化,当然了,这个对象还可以在网络上序列化。达到两个目的:
1. 数据库表与对象自动映射,不需要认为写结构体与数据库表字段一一对应
2. 数据库操作均通过对象与固有接口进行配合,不需要单独写拼接sql语句接口(解释得有点模糊,下面继续解释)
横向比较:
这里列出与另外两个数据库操作库进行对比
proto_db DTL OTL 模型 基于protobuf,采用简单接口操作 基于ODBC,类采用STL算法与数据结构的操作 基于各种数据库提供的API,采用IOstream流式操作 易用性 十分简单 简单 简单 稳定性 个人作品,未商业,还不太成熟 可靠 可靠 扩展性 方便 比较容易 不容易
设计思路:
使用示例:
先来看看接口
// 插入 bool sql_insert(const google::protobuf::Message &msg); // 修改 bool sql_update(const google::protobuf::Message &msg, const google::protobuf::Message &where); // 删除 bool sql_delete(const google::protobuf::Message &where); // 查询 template < typename T, typename ColumnT > std::vector<std::shared_ptr<T>> sql_select(const ColumnT &cols, const where_t &where);接口需要通过传入protobuffer对象来完成。对于select,需要传入所需要的column名称和查询的数据库,所以比较奇怪
在这里,我们假设有个person的message对象,含有三个属性name、id、email。
来一个插入的例子:
Person person; person.set_name("test name"); //person.set_email("test@qq.com"); person.set_id(1); query.sql_insert(person);在这里,person只设置了name属性,在实际插入一条新纪录,但并不会把email和id同时插入,插入的这条数据中只包含name字段。也就达到了效果。
看一个更新的例子:
Person person; person.set_name("test name"); person.set_email("test@qq.com"); Person where_t; where_t.set_id(1); query.sql_update(person, where_t);在这里,使用了两个person对象,第一个person对象设置了名字和email,第二个Person对象只设置了id,也就是说我们的更新会根据where_t的id值来更新对应记录的name和email。是不是特别方便呢?
查询是不是就有点麻烦了呢?
// select Person person; typedef std::shared_ptr<Person> person_ptr; std::vector<person_ptr> persons = query.sql_select<Person>( all_columns_t(), (where_t("id") == 1 && where_t("name") == "test name")); std::for_each(persons.begin(), persons.end(), [](const person_ptr &val) { std::cout << val->name() << " " << val->id() << " " << val->email() << std::endl; });现在的接口查询出来的数据只能是vector类型的。
性能:
整体性能会比直接采用连接库会多一些,具体在这方面:
1. 构建SQL语句会有动态开销
2. protobuf解析会有动态开销
约束:
由于protobuffer实现时使用了反射,所以有两点约束:
1. 数据库名就是对象名
2. 数据库表中字段名就是对象属性接口名
为了减轻重复性工作,顺便提供了一个遍历数据库表,生成对应CPP文件的工具。如果有兴趣可以看看。
展望:
protobuffer是非常强大的武器,不仅仅可以用来做序列化,还可以很多很多。希望借助于protobuffer来完成一个从数据库到网络对象操作服务。其实这种技术在其他语言早就有了,这里只是在模仿,减轻平时C++开发的工作量提高生产率。
接下来的改进:
1. 采用连接池
2. 数据库连接层进行抽象,支持更多数据库操作库
3. 加强LINQ语法,提供高级功能,例如:排序,group,join等等
下载
该库大量使用C++11语法,如果希望能探讨更多C++学院派的新奇玩意儿,可以加入此群165666547(打了个小广告)