SmartPersistenceLayer之设计功能篇
持久层SmartPersistenceLayer以下都简称为SPL,目前版本为2.0.
持久层概念
数据层透明
目前在网络上大家可以找到好几种持久层，其实各个持久层的思想都是相同的，只是在实现的方式上，还有一些细节功能上有差异，每个持久层都有独特之处或是不足之处，这本身是一个发展过程，SPL也不例外，我同样希望有朋友能提出问题，能让持久层更加完善。
持久层(下面我都以PL来代替持久层)是作为系统开发的一个低层平台，所有涉及的数据库操作通过PL来实现，使用O/R Mapping的方式使用业务对象与数据库进行分隔，因为从思想角度来看的话，业务逻辑本身与数据库不应该有太多的约束，业务逻辑是千变万化的，那么业务逻辑不应该受到数据库的牵制，因此系统采用什么样的数据库(SQL Server,Oracle等)，对于业务逻辑层面来看，那都是数据库，只要能实现关系型数据库的功能就可以。
所以，PL最根本的一个功能，就是使用业务逻辑与数据层分离，让系统开发对数据库透明。
SPL目前支持SQL Server，Access,Oracle，对于SQL和Access，SPL会自动产生sqlConnection,其他数据库采用OleDbConnection连接。这也是MS推荐的方式。
实体映射
在ORM原理中我们可以理解到，为了让业务逻辑的开发与数据库能具有这种对应关系，采用Object Relational映射来实现，也就是在业务系统中定义“实体Entity”，那么通过一个XML文件实现Entity与Table的映射，然后业务系统中对Entity的操作，通过PL与XML映射来完成真正的数据库访问。
SPL中的Entity与其他PL不同的地方，SPL采用继承ObjectEntity的方式来实现Entity本身的增删改操作，这种实现方式更加对象化，更能站系统开发站在OO的层面上，目前SPL中提供Entity的Retrieve(获取)，Save(保存),Delete(删除)功能。在这些操作中，开发员真正意义上的面向对象开发、对数据层彻底透明，不需要任何一句SQL语句就实现多数据库操作。
这将解决SQL编写造成的开发速度慢、语句调试复杂、容易出错，扩展性差等不足。
关系映射
从ORM的理论上，除了实体外，还有一个Relational功能，也就是用Entity与Entity之间的关系来实现数据库里的表表关系。这种Relational具有相当的复杂度，网络上有些PL也实现了Relational，这应该是一个比较好的开始，具体的功能与效果我也没有偿试过。
由于这种复杂性，SPL中目前去掉了Relational功能，我需要更多的时间来考虑如何让系统开发对Relational更加方便。
也可能是这方面，使SPL比其他的PL要容易上手，容易理解。
SPL特性
SPL在完成以上实体功能的基础上，增加了一些特性，我简单介绍一下先，这些都会在后续的文档中发布。
标准Criteria
Criteria是指标准，目前的SPL分为RetrieveCriteria(获取标准),UpdateCriteria(更新标准),DeleteCriteria(删除标准)，这些标准也都是针对一个实体进行操作的。
RetrieveCrietria(获取标准)
可以通过RetrieveCriteria进行一个实体的高级查询，比如定义查询条件，定义排序方式等，举个简单例子：
目前有个StudentEntity实体，要实现“查询所有的姓刘的同学，并以学号进行排序”：
RetrieveCriteria rc=new RetrieveCriteria(typeof(StudentEntity)); //实例化
Condition c=rc.GetNewCondition(); //创建一个条件
c.AddMatchPerfix(StudentEntity.Name,’刘’); //这会生成name like ‘刘%’的查询
rc.OrderBy(StudentEntity.No); //这会生成order by No
DataTable dt=rc.AsDataTable(); //这以DataTable的方式返回
关于Condition类将在以后进行讲解，RetrieveCriteria提供多种返回方式，方便对返回结果进行操作，如果是进行数据绑定，则直接以DataTable返回;如果是要进行操作,则使用AsEntityContainer方式返回Entity集合.
UpdateCriteria(更新标准)与DeleteCriteria(删除标准)
UpdateCriteria是产生Update table set Name=’xx’ where ….的语句
DeleteCriteria 是产生Delete from table where …的语句
使用方式类似于RetrieveCriteria ,将在以后文档中进行详细讲解
事务处理
事务处理可能是系统开发中最经常用到的了，SPL中的事务处理相当简单，前面介绍的那些操作都可以以事务的方式进行处理：
Transaction t=new Transaction();
t.AddSaveObject(ObjectEntity)
添加Entity的保存到事务中，根据Entity的IsPersistence自动进行判断Insert和Update
t.AddDeleteObject(ObjectEntity)
添加Entity删除到事务中
t.AddDeleteCriteria(DeleteCriteria)
添加删除标准到事务中
t.AddUpdateCriteria(UpdateCriteria)
添加更新标准到事务中
t.AddSqlString(sqlString,db)
添加SQL执行语句到事务中
t.Process()
执行事务提交，如果遇到错误，事务全部rollback.
Query高级查询
Query是一个功能强大的查询类，可以进行Entity之间的联合查询，也可以使用Query的一些静态进行数据库操作。
Query的联合查询功能目前支持内联接，没有实现左联接，由于查询本身是个最复杂的东西，所以在我的设计方案中，我一般是采用视图来进行联合查询。
Query. ProcessSql(sqlString,”db”)
静态执行SQL语句，对于一些SPL无法实现的功能，可以使用此SQL语句进行处理
Query还支持简单的汇总查询，具体功能在以后文档中进行讲解
支持自动增长字段
自动增长的字段，在SPL中不需要指明，会自动进行值增长，并马上返回到系统实体中，以便进行后继处理,比如新增了订单主档后，会把订单生成的ID返回到Entity中，以便于进行订单明细保存时使用。
动态数据源配置
默认情况下数据源会从XML配置文件里读里，系统也提供使用代码直接Add一个数据源连接。
多帐套支持
在大型系统中会使用到多帐套，也就是一些完全一样的表实体，只是数据源不同,这种我就称之为多帐套，SPL中支持多帐套，也就是所有的操作都可以在系统中手动设置databaseName，这样会更新到不同的数据库中。
内存存储
这个功能应该是目前国内市场上唯一的一个了。
对于一些维护型的数据，由于其数据量少，字段少，维护频率低，使用率高等特点，为了提高系统的整体性能，这些数据可以保存在内存中，减少数据库的访问，SPL中要使用此功能非常简单，只要要声明Entity时，指明”IsSaveToMemory=true”即可，这样，SPL在第一次获取后，会保存到内存中，以后的读取会自动从内存中获得，这个Entity的更新，比如Insert,Update,Delete等操作会根据IsSaveToMemory自动更新到内存，也就是对于开发员来说，这个功能是完全透明的。第二：内存存储也是支持多帐套的，也就是同样的Entity，如果是从不同的数据库取得的，会生成两个内存复本，以后的读取与修改也都是以自己的帐套为准的。
以上我是简单介绍了一个SPL的设计出发点与功能点，详细的介绍我将会在后继发布文档。
希望有兴趣的朋友，能对SPL提出意见，以便让SPL能更加完善。
听棠
2004年11月
MSN:tintown_liu@hotmail.com
