背景:
最近在工作中,受到大量数据库操作的折磨。由于采用拼接字符串的方式来进行数据库操作,带来了每个数据库操作业务都需要提供一个接口,导致同一张表的操作需要一堆堆接口。比如表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等等
下载
github:https://github.com/chenyu2202863/proto_db.git
该库大量使用C++11语法,如果希望能探讨更多C++学院派的新奇玩意儿,可以加入此群165666547(打了个小广告)
原文链接: https://www.cnblogs.com/yu-yu/archive/2013/03/05/2944278.html
欢迎关注
微信关注下方公众号,第一时间获取干货硬货;公众号内回复【pdf】免费获取数百本计算机经典书籍
原创文章受到原创版权保护。转载请注明出处:https://www.ccppcoding.com/archives/79773
非原创文章文中已经注明原地址,如有侵权,联系删除
关注公众号【高性能架构探索】,第一时间获取最新文章
转载文章受原作者版权保护。转载请注明原作者出处!