个人orm开发记录

这些改进虽然不是很多很难，但是期间由于上司的不理解，不允许，不支持，到现在还包括不能使用ORM，不接受C++/CLI以外的代码，不接受config文件等等一些问题的存在。

我也提出过辞职，但在老总的挽留和其他一些原因下我还是在坚持，我尽自己的能力使公司的产品向好的方向发展，我想最终我的上司也会有所改变。

回到正题，在工作的时候我尝试开发下面这样一套简单的ORM，如果以后的有一天被允许用在公司的项目中，我想我的这次学习也没有错。

本着最小接口的原则，开发初期首先要确定需要提供的接口，所以在我的脑子里描述出了以下2个接口：

第一个是DAL的接口：

在IDataProvider接口中我需要基础数据库提供基本的4种Excute操作；

第二个是IEntity的接口：

IEntity接口也很简单，对一个实体的操作我需要的是基本的CURD操作；

确定了这2个基础接口的想法后，我开始了尝试开发，对于实现IDataProvider接口缩小了说就是一个SqlHelper的东西，放大点就是需要兼容SQL、Access、MySql等各类数据库的一个DAL，所以在命名上的我选择了Provider也就是不想它只是一个SqlHelper。

在之前我已经看过并简化过Microsoft Enterprise Library 5.0中Data Block的代码，所以对于IDataProvider的实现也很轻松的就完成了，基本仿照Enterprise Library实现了如下代码：

其中DataProvider是实现IDataProvider接口的基类，并且定义成了抽象基类，要能够实例这个DataProvider又派生了一个继承类GenericProvider；

其实从确定使用最小接口开发到时候，我就想提供最少的接口给外部调用，所以只留了IDataProvider为public的，其他的都为internal级别，这个接口要能实例一个对象，则必须要提供一个public方法获取实例好的接口对象，所以我又提供了一个静态类DbHelper，最初的DbHelper类代码如下：

publicstaticclassDbHelper
{

///

///数据库类型

///连接字符串

///接口实例

publicstaticIDataProvider CreateDataProvider(ProviderType provider,stringconn)

{

IDataProvider DbProvider=null;

stringcharacter="@";

switch(provider)

{

caseProviderType.SQLSERVER:

DbProvider=newGenericProvider(conn, SqlClientFactory.Instance);

break;





caseProviderType.ACCESS:

DbProvider=newGenericProvider(conn, OleDbFactory.Instance);

break;

/

case ProviderType.ORACLE:

character=":";

DbProvider = new GenericProvider(conn,OracleClientFactory.Instance);

break;

/

default:

thrownewNotImplementedException("数据库类型不支持");

}

DbProvider.ParameterCharacter=character;//此处要设置下 ParameterCharacter

returnDbProvider;

}

}

到这一步，一个基本的DAL已经完成了。

对于实现IEntity，还是绕了一些弯路的，一开始我的想法是，一个泛型基类EntityBase实现IEntity接口，然后由实体继承EntityBase,这样实体就拥有了Save Update Delete等方法。

同时也查找了一些文章发现也确有很多如此实现的，但是除了Save、Update放之外，对于Find方法如果被约束为实例方法则好像不太合理，如果约束为静态方法，那么实体继承后，用实体Find出实体好像也不太让我满意。例如:

classUserInfo:EntityBase<UserInfo>{}

使用时：

1，

IList<UserInfo>users=UserInfo.FindAll();

2，

UserInfouser=newUserInfo();

IList<UserInfo>users=user.FindAll();

这两种方法都会让我看起来感觉不满意，所以在IEntity的实现上我最后并没有选择让实体都继承一个EntityBase这种方式，

于是我重新定义了IEntityHelper接口，想通过一个EntityHelper实现了进行对实体的CURD操作，

重新定义的IEntityHelper接口如下：

///

publicinterfaceIEntityHelper

{

///

eventEventHandler<DebugSqlArgs>DebugSql;



///

///

///

///

boolInsert<TEntity>(TEntity entity)whereTEntity :new();



///

///

///

///

boolDelete<TEntity>(TEntity entity)whereTEntity :new();



///

///

///

///

boolUpdate<TEntity>(TEntity entity)whereTEntity :new();



///

///

///

///

IList<TEntity>Select<TEntity>(paramsIQuery[] querys)whereTEntity :new();



///

///

///

///

TEntity FindOne<TEntity>(paramsIQuery[] querys)whereTEntity :new();



}

对于ORM中比较重要的SQL语句的生成，我定义了一个IQuery接口以便在Select查询的时候传递查询条件，并用一个单独的SqlBulider静态类提供的方法生成SQL语句。

确立了上面的想法之后就是实际的EntityHelper的开发了，实际上当我们去了解orm的时候就知道，Object RelationMapping就是建立关系数据与实体对象的映射，如何将实体对象与关系数据(表)进行映射，就需要对象能够描述表，比如表名、字段、字段的属性等等。

首先要建立对象与表对应的关系的时候，有几种建立方法，用配置文件，用字段、属性描述，这些都能达到实体对象与表建立一个对应关系，但是并不是一个好的处理方法。有很多前辈已经研究过这些方面，并提出了用Attribute进行描述的方式，这里我也很自然的选择使用这种方式加入到我的开发。

当然，本着尝试开发的心态，并没有想一下开发或者构思好一个完整的框架，所以能省略的东西我也省略了，包括对字段的描述只标注简单的属性：

///

internalclassField

{

///

internalPropertyInfo Property

{

get;

set;

}



///

internalstringName

{

get;

set;

}



///

internalDbType Type

{

get;

set;

}



///

internalboolIdentify

{

get;

set;

}



///

internalboolPrimaryKey

{

get;

set;

}

}

有了把实体对象和数据表进行对应这一基础之后，我们需要考虑的就是真正的Save、Delete这些方法执行时是如何将一个实体对象的属性解析出来（这里就相当于在准备SQL操作时，如何从实体对象中知知道与其对应的数据表操作的信息）， 这里实际有一个前提， 我们的EntityHelper的Save等方法都是泛型方法，所以它们自身并不知道传递进去的对象是怎样一个结构，也并不到这个结构具体的数据。

通过学习我们知道.net中的反射机制，通过反射来动态的解析一个对象在中变比较简单，深层次的原理我们不必要知道，做为最普通的“IT码工”，站在我的层次上我只要能够使用并知道大概就可以了。

所以在前人的基础上，我的orm也自然离不开用反射获取从实体对象到SQL操作需要的表信息，但是在学习的基础上，也离不开我们自己的思考，反射相对于直接操作是比较耗费时间的，所以此时就有一个orm与直接数据操作的效率问题成为了大家关注的问题。

很多前辈 很多orm讨论已经告诉我们需要用缓存来降低发射对性能的消耗，所以我的orm中也必须使用缓存来降低反射这种损耗。

在学习过程中我没有直接接触那些比较大的orm框架，都只是查看一些讨论的博文，顺便下载了一些博文附带的orm实现示例，在此过程中学到了很多但也发现了一些问题：

如：有的orm根本没有注意反射对性能的影响，没有一个缓存机制，有的orm在执行Svae、delete等方法时返回void类型 根本无法判断执行是否成功，还有的明确要求对于数据表要包含自增主键，但是它自身的Save方法执行后并没有获取自增主键值来更新实体的属性；

这些问题虽然致使这些组件不能很好的做实际应用，但是从中学习到的是更多的东西，通过这些也让自己思考如何更好的实现，如何避免这些错误的方式方法。

到此为止，首先通过自己思考提出最小接口，再通过学习现有orm的讨论和实现示例，然后确定一个开发流程做到心中有数。心中有数了，其实就变的就非常简单了，按照构思好的接口，实现一个EntityHelper就可以了，对于如何实现EntityHelper在查阅资料与学习的过程中已经有了清晰的线路，我自己简要概括出了如下路线：

由于是尝试性的按最小开发，所以我的要求是开发一个简单基础的orm，此处的orm可能并不是真正的orm，只是一个能让实体通过Save等面向对象方法来代替数据库Excute操作的东西。

有了思考之后是实际的开发，实际开发其实也就是EntityHelper的开发，在Save、Update、Delete方法实现时都比较简单，基本实现类似如下：

///

///实体类型

///实体对象

///成功/失败

publicboolDelete<TEntity>(TEntity entity)whereTEntity :new()

{

Table table=TableFactory.GetTable(typeof(TEntity));

stringsqlText=SqlBulider.Delete(table, entity, DbProvider.ParameterCharacter);

DbParameter parameter=DbProvider.Parameter;

foreach(var fieldintable.Fields)

{

if(field.PrimaryKey)//删除时根据主键删除

{

parameter.ParameterName=DbProvider.ParameterCharacter+field.Name;

objectvalue=field.Property.GetValue(entity,null);

parameter.Value=value==null?DBNull.Value : value;//取字段值

parameter.DbType=field.Type;

break;

}

}

StringBuilder debugSql=newStringBuilder(sqlText);

debugSql.Append(Environment.NewLine);

debugSql.Append("<");

debugSql.Append(parameter.ParameterName);

debugSql.Append("=");

if(parameter.Value!=null)

debugSql.Append(parameter.Value.ToString());

debugSql.Append(">");

if(_debugsql!=null)

_debugsql(this,newDebugSqlArgs("Delete",typeof(TEntity).Name, debugSql.ToString()));

returnDbProvider.ExecuteNonQuery(sqlText, parameter)==1;

}

实现Delete方法的流程是：

在Find方法实现时有些不同，主要就是Find方法实现的是数据库的Select操作，往往包含一些查询条件，如=、between、like、order by这些操作，所以此处就有点为了orm而orm的意味了，为了避免Find方法的参数包含直接的SQL语句，所以我定义了一个IQuery的接口:

这个接口比较简单，有一个方法Context为输出sql查询子句，后来在分析过程中考虑到由于实体属性对应数据表字段，而且所有的Excute操作都要参数传递的，所以在后面的分析思考中又添加了一个字段名，和一个Hashtable表存放参数值；

IQuery

为什么用Hashtable存放参数值呢，是因为出现类似between查询时 形如：where id between @id1 and @id2,这个时候拥有2个参数@id1,@id2不能全部由字段名id来表示，所以需要一个Hashtable存在该查询对象的查询参数。

这样大概的一个基本的orm形态就完成了。后面的一些工作就是一些细节方面的东西了，主要的细节包括以下：

1,EntityHelper中的IDataProvider对象的存在方式，是静态成员还是实例成员?EntityHelper是否可以为静态类，Save等方法是否可以为静态方法?

在考虑这个问题的时候其实要联系到 前面提到的DbHelper，DbHelper中staticIDataProviderCreateDataProvider(ProviderTypeprovider,stringconn)方法根据传递的ProviderType和conn来确定使用何种数据库对象，

同时提供它的一个重载方法staticIDataProviderCreateDataProvider()通过这个重载方法大家肯定会想到一个DataProvider应该有一个通过配置文件配置所使用数据库类型的功能，我的orm也不例外， 不过只是一个简单的实现用一个可序列化的对象ProviderConfig序列为XML文件来保存的。

那这个跟EntityHelper有什么关系呢，我们一般的情况下可能一个程序中使用一种数据库就可以了，此时我的EntityHelper种的DataProvider对象不管是静态的也好，还是实例化的也好，可能不需要太注意，应为一个程序中只可能存在一种数据库操作的DataProvider。

现在就提出了一个问题，假如我有一个Access数据库，一个SQL数据库，我想在程序中将SQL的数据添加到Access中，那此时用一个EntityHelper操作时DataProvider就只能是实例成员了，因为我可以通过staticIDataProviderCreateDataProvider(ProviderTypeprovider,stringconn)方法实例2个不同数据库的DataProvider，同时实例2个不同的EntityHelper对象来操作2种数据库；

这样上面的这个问题就解决了。

2,如果使用缓存减少反射的性能损耗，在哪里使用缓存，这也是一个问题?

实际上通过实现Save等方法时，第一步就是反射实体，这里我们自然的就想到 能否将实体结构缓存起来不用每次都反射呢?答案当然是肯定的，面向对象的开发里就是需要将所见所想能抽象出来用对象描述。这里我实现了另外2个类用来这部分操作:

这样在Save方法中第一句代码Tabletable=TableFactory.GetTable(typeof(TEntity));

就可以想到TableFactory.GetTable方法是要从缓存判断有没有Tentity对象的结构，来看下这个方法就比较清楚了：

///

internalclassTableFactory

{

///

privatestaticDictionary<string, Table>cache=newDictionary<string, Table>();



///

///对象类型

///Table对象

publicstaticTable GetTable(Type type)

{

if(cache.ContainsKey(type.FullName))//使用类型FullName做Key

{

returncache[type.FullName];

}

returnBulidTable(type);

}



///

///对象类型

///新的Table对象

privatestaticTable BulidTable(Type type)

{

Table table=newTable(type);//创建新的对象

cache.Add(type.FullName, table);

returntable;

}

}

通过上面的方法也解决了缓存问题。 虽然是一个简单基本的缓存，但是这仅仅只是用在这个尝试性的orm开发中，所以这一切都只是一个学习，也足够了。

3,接下来来的一个问题是参数符号，也就是“@” 和 “：”

这个问题在一开始开发DataProvider时我并没有想到，所以这个时候就不得不去修改IDataProvider接口，为其添加下面2个属性：

///

DbParameterParameter{get;}

///

stringParameterCharacter{get;set;}

至于为什么要这么添加，也是由于Save方法的实现需要和DataProvider的已经完成，所以这里也让我知道设计是多么的重要，一个好的设计可以适合很多复杂情景并且不会有问题。

对于这一处修改而牵扯的其他修改就更不必说了。

4,在Save方法中还有一个很重要的方面就是前面提到过的一些orm的缺点，那就是没有更新自增列的值.

在我查阅了一些资料之后先是使用了 输出参数的方式，在insert语句后面添加一个输出参数用SCOPE_IDENTITY来取自增值；但是这样做了之后再最后的测试时才发现了问题，Access不支持输出参数，所以真是让人懊恼！

因为这个问题，无奈第2此修改IDataProvider接口，因为我打算用事务来获取自增列值，具体的方法为：

///

///表名

///SQL语句

///参数

///自增列值

publicintExecuteForIdentity(stringtablename,stringquery,paramsIDataParameter[] parameters)

{

using(var wapper=GetWapperConnection())

{

using(DbCommand command=PrepareCommand(wapper.Connection, query, parameters))

{

try{

DbTransaction transaction=wapper.Connection.BeginTransaction();

command.Transaction=transaction;

if(command.ExecuteNonQuery()>0)

{

command.CommandText="SELECT @@IDENTITY FROM"+tablename;

transaction.Commit();

intid=Convert.ToInt32(command.ExecuteScalar());

returnid;

}

else

return0;

}

catch

{

return-1;

}



}

}

所以增加了一个int ExecuteForIdentity方法供Save时使用， 这样算是简单的解决了自增列的问题，但是还面临ORACLE数据库取自增值的问题，所以这里我权衡了下，自己对ORACLE了解的也比较少，自己的项目中也不会用到ORACLE，所以干脆就屏蔽掉了对ORACLE数据库的考虑！最终使我这个orm只支持了access和sql server。

5,还有一个问题也是在测试的时候发现的，与access数据库有关的

当我们执行一句形如 ：update Table values(@age,@name) where id=@id这样的一句SQL语句是不会有问题的，但是此时如果你要将@age @name @id的参数顺序搞错了，那可就不一定了…一个“标准表达式中数据类型不匹配”的异常就让我在这吃了一次亏，还好后来查到了问题原因， 是因为我在添加DbCommand的参数的时候是按照反射来的属性顺序添加的@id就被添加到了第一个，造成了这种access数据库的异常，实际上where查询后的参数应该放在后面，到这里基本上的问题都被处理掉了，我的orm也算是成型了。

最后就是测试了，当然测试的基础就是按照一开始自己构思的接口，如何使用这个orm,下面我就贴出一段测试代码：

TestAccessprivatestaticvoidTestAccess()

{

stringconn="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\db.mdb;";

IDataProvider dbp=DbHelper.CreateDataProvider(ProviderType.ACCESS, conn);

if(dbp.ConnectAvailable==false)

{

Console.WriteLine("数据库连接不可用");

Console.ReadLine();

return;

}

helper=newEntityHelper(dbp);

helper.DebugSql+=newEventHandler<DebugSqlArgs>((obj, e)=>Console.WriteLine(e.Context));



XUser user=newXUser()

{

Name="x",

Age=-1

};

for(inti=0; i<10;++i)

{

booldelete=helper.Delete<XUser>(user);

Console.WriteLine("Delete={0}", delete);



boolinsert=helper.Insert<XUser>(user);

Console.WriteLine("Insert={0},XUser.id={1}", insert, user.Id);



user.Age=i+10;

boolupdate=helper.Update<XUser>(user);

Console.WriteLine("Update={0}", update);

}

IList<XUser>users=helper.Select<XUser>();

foreach(var iuserinusers)

{

Console.WriteLine("IUser.Id={0},Name={1},Age={2}", iuser.Id, iuser.Name, iuser.Age);

}

}

TestSqlprivatestaticvoidTestSql()

{



stringconn="Data Source=localhost,8306;Initial Catalog=SensorLeadDB2;User ID=sa;Password=HZ.bridge";

IDataProvider dbp=DbHelper.CreateDataProvider(ProviderType.SQLSERVER, conn);

if(dbp.ConnectAvailable==false)

{

Console.WriteLine("数据库连接不可用");

Console.ReadLine();

return;

}



helper=newEntityHelper(dbp);

helper.DebugSql+=newEventHandler<DebugSqlArgs>((obj, e)=>Console.WriteLine(e.Context));



UserInfo user=newUserInfo()

{

Name="hello",

Age=0,

Marry=false,

Brithday=DateTime.Now,

Phone="000"

};

for(inti=0; i<10;++i)

{

booldelete=helper.Delete<UserInfo>(user);

Console.WriteLine("Delete={0}", delete);



boolinsert=helper.Insert<UserInfo>(user);

Console.WriteLine("Insert={0},User.Id={1}", insert, user.Id);



user.Age=i+10;

boolupdate=helper.Update<UserInfo>(user);

Console.WriteLine("Update={0}", update);

}



IList<UserInfo>users=helper.Select<UserInfo>(newQueryCompare(CompareType.Equal,"Marry",false),

newQueryOrder("Age"));

foreach(var iuserinusers)

{

Console.WriteLine("iUser.Id={0},Name={1},Age={2}", iuser.Id, iuser.Name, iuser.Age);

}

}

经过测试与完善，最后自己还是比较满意的，主要在于是自己思考动手的结果，在这里呢，也将这个简单过程记录下来，希望留给其他需要的朋友一些帮助。

到这里发现程序员用语言来描述思维真的是比较困难，所以照例我会上传项目源码 ，方便需要的朋友分析，也希望能得和大家共同交流学习。

/Files/cxwx/Bridge.Data.rar