前言
为了让Dlang像 Java / PHP / C# 一样具有非常好的数据库操作体验,我们了解了 PDO、JDBC、HIBERNATE、ADO.NET,最终发现大家的设计都不是很统一,只有 Java 最新的持久化标准 JPA 是真正的具有可移植性,所以我们准备自己实现一套 JPA 机制,命名为 dlang-entity。
分析
分析的时候发现 dlang 官方没有任何标准的数据库操作接口,也就是像 PDO / JDBC / ADO.NET 这样的东东都不存在……
继续分析发现上层还有 SQL BUILDER ,最上层还有 Entity 的一系列管理,最终我们把 ORM 分成了 4 个层,分别是 Database / DBAL / CriteriaQuery/ Entity
层次功能
- Database 负责基础的数据库访问,接收 SQL 语句,类似于 PDO、JDBC、ADO.NET;
- DBAL 负责实现 SQL BUILDER,依赖 Database;
- CriteriaQuery 是调用 DBAL 层,和 Entity 的实体进行关系绑定;
- Entity 见名之意就是实体,下面依赖 DBAL 和 CriteriaQuery。
难点分析
上面的架构是分层实现,但是对于功能来说是从外而内,Database 和 Entity 是同步设计的,目前参考了 JPA 的接口设计,也认为是一种标准,但是存在的问题是语言之间的特性不同,Java 在 JPA 的设计上使用了很多运行时注解特性,虽然设计简单但是性能肯定是不理想,但是研究了 dlang 的方案后发现很多东西不能在运行时处理,因为 dlang 的编译时非常牛,虽然 dlang 这样的实现会让性能达到极致,但是也同时很大程度的增加了开发的复杂度。
比如,参照 JPA 的设计用 dlang 可以这样:
1class User 2{ 3 int id; 4 5 string name; 6 7 int age; 8 9 int high; 10} 11 12class UserModel 13{ 14 User[] getUsers(String name, int age, int high) 15 { 16 CriteriaBuilder cb = em.getCriteriaBuilder(); 17 18 CriteriaQuery query = cb.createQuery!User(); 19 20 //from 21 Root root = query.from(typeid(User)); 22 23 //where 24 25 Predicate p1 = cb.like(root.get("name"), "%" ~ name ~ "%"); 26 27 Predicate p2 = cb.equal(root.get("age"), age); 28 29 Predicate p3 = cb.equal(root.get("high"), high); 30 31 Predicate p = cb.and(p1, cb.or(p2, p3)); 32 33 query.where(p); 34 35 User[] users; 36 37 auto result = em.createQuery(query).getResult(); 38 39 foreach(auto user; result) 40 { 41 users ~= user; 42 } 43 44 return users; 45 } 46}
当然是不是行得通还有待验证,后续再持续更新本文章。
未完待续!
~~~~~~~~~~ 2018.12.13 ~~~~~~~~~~~~
现在 hunt-entity 已经支持了完整的 JPA 实现,并且提供了 EQL 来对标 JPA 的 JPQL 来支持复杂查询,项目地址: