基于配置的ORMapping框架浅析之1

基于配置的ORMapping框架浅析之1（以自己开发的框架为例子） 收藏

 

 

框架编程目前已经是一种构建伸缩性和高可用性的一种很普遍采用的方式，框架编程的优点有很多，它把思想和技术有机的集合在一起，通过阅读框架，其实也就阅读了开发者的思想。

 

目前我们主要讨论持久化框架，先不讨论基于业务的框架模型

持久化模型框架一般都提供了ORMapping映射关系，一般通过配置文件来描述对象与对象间的关系，对象与数据表间的关系，数据表间的关系

   类表映射：对于业务模型中的每一个对象，在数据库中都有一个表与之对应

    具体表映射：对于业务模型中被定义为接口或抽象类的对象，在数据库中没有这些表，这些对象的字段是映射到子类中的

    单表映射：对于业务模型中的对象，在数据库中只有一张表与之对应

 

那么我在框架中常常采用类表映射机制，当然这种机制的好处是不用多说的，对象关系图基本就是数据库关系图，直观。缺点也存在，当对象很多的时候，如果数据库表的数据量很大的时候，肯定是影响效率的；而且对于代码开发人员来说，开发的复杂度也较高。

 

具体表映射应该是一种折中方案，基本兼顾对象业务分离 和数据库效率

单表基本不采用

 

以下阐述一下框架整体结构：

 

框架以微软企业库4为底层核心，提供了AOP方面编程，依赖注入技术和自定义类生成器工具。

0）框架采用了类表映射模式开发（尚不能定制扩展成具体表映射方式，在下一个版本中可能需要增加这个类容）

1）分布式事务提供了两种方式：一种是TransactionScope 一种就是使用COMPLus

 分布式事务都是使用了AOP技术进行程序代码分离，因此在业务逻辑代码中是不需要显示的去调用这些分布式事务的类和接口。

2）框架支持标签声明式变成和配置文件编程两种方式，提高灵活性

3）支持今后的读写数据分离操作，提高数据库的效率

4）准备集成复杂对象查询机制（考虑使用 Antltr ，不过现在有了Linq，目前尚在构思阶段）

 

Core.Entity   实体类库

CoreLibrary   数据访问层

CoreFrameWork.COMPlusTransaction  COMPlus 事务库

AspectModule 目录下是 面向方面的类库

 

Core.Entity   实体类库 讲解

持久实体结构采用了类表映射原理，并且对象间的关联采用Key值关联模式

Key关联模式 ： 使用表中主键作为对象间关联标识

对象关联模式：使用对象作为对象间关联模式

 

1. public class Dept
2. {
3.    public string DeptName
4.    {
5.      get;
6.      set;
7.    }
8.    
9.    public List<int> UserList
10.    {
11.      get;
12.      set;
13.    }
14. }
15. public class User
16. {
17.   public int DeptID
18.   {
19.     get;
20.     set;
21.   }
22. }
23. 以上是Key值关联
24. public class Dept
25. {
26.    public string DeptName
27.    {
28.      get;
29.      set;
30.    }
31.    
32.    public List<User> UserList
33.    {
34.      get;
35.      set;
36.    }
37. }
38. public class User
39. {
40.   public Dept Dept
41.   {
42.     get;
43.     set;
44.   }
45. }
46. 以上是对象值关联

优缺点:

Key值关联避免了延迟加载等复杂的机制,仅仅是依靠ID值来作为对象的关联桥梁,数据库查询时速度快,不用拉一对其他的数据出来,如果用对象关联模式,则需要在这些方面加入延迟加载机制,否则效率太低.

 

因此Core.Entity 中的类不多

 

1. /// <summary>
2.     /// 领域接口标志性接口
3.     /// </summary>
4.     public interface IDomainObject
5.     {
6.         Guid Key
7.         {
8.             get;
9.             set;
10.         }
11.         int Version
12.         {
13.             get;
14.             set;
15.         }
16.         bool IsDirty
17.         {
18.             get;
19.             set;
20.         }
21.         IDomainObject CloneObject();
22.         
23.     }

可以看到主键采用的是GUID ，为什么采用GUID？

除了唯一性外，还有一点是考虑数据库性能方面，因为GUID是唯一的而且也是随机的，没有后一个GUID的值一定大于前面一个GUID的值的说法，因此在表中的分布是平均的，不会像INT型的增量数据，热区始终在表的末尾，表的末尾承受数据的压力也就最大，因此在大数据量访问和更新的时候，会影响效率。但用GUID就不会出现这种现象。

 

框架的很多中考虑都是考虑配合数据库效率方面而做的。

原文出处：http://blog.sina.com.cn/s/blog_53a072c10100l7uv.html