分析
要做一个基于数据库的应用程序，我们有大量的重复劳动要去做，建表，写增删改查的SQL语句，写与数据库表对应的实体类，写执行SQL的c#代码，写添加、修改、列表、详细页面等等。这些活动都是围绕着一个个都数据表来开展的，在.NET领域有很多的OR Mapping的方案，但好多方案用起来好用，但原理很复杂，而且性能也不好把握，所以我们可以做一个轻型的ORM方案。有了ORM框架，根据数据表写c#实体类这些劳动，其实也可以写一个代码生成器来帮我们生成，甚至代码生成器还能帮我们生成一些界面的代码。我们大概需要解决如下问题
1、我们要有一个通用的数据库操作帮助类，类似微软的DAAB，但最好能支持多种数据库；
2、我们要有一个使用简单的orm框架，能方便的用c#代码来进行数据库存取操作，而且要尽量保证性能，比如使用参数化查询；
3、我们要有一个代码生成器帮助我们解决一些重复性劳动，比如生成实体类，生成调用存储过程的c#代码等；
围绕这3个问题，我们一一来展开
一、通用的数据库吃操作帮助类
ADO.NET 2.0为我们访问数据库提供了一套与具体数据库无关的模型，其核心类是DbProviderFactory，它遵循了Provider模式，就是把对各种数据库的操作抽象出一个Provider，再由各种数据库去写与具体数据库相关的Provider，然后通过配置在运行时方便的切换数据库，而尽量少的不修改业务逻辑层的代码，业务逻辑层依赖的是抽象的Provider。这也是典型的依赖倒置，就是说业务逻辑说我需要哪些接口，我依赖这些接口，而让别人去实现这些接口，在运行的时候再去加载调用实现这些接口的具体类。
为了提高性能，减少SQLSERVER执行计划的重编译，我们尽量使用参数化的查询，而一个固定的语句或者存储过程它的ADO.NET参数是固定的，所以我们可以把这些参数缓存起来，避免每次执行SQL语句都创新新的参数对象。另外oledb的ado.net provider的参数是不能命名的，所以给参数赋值要按顺序赋值。
为了使用方便，我们为执行SQL语句提供如下的API
public System.Data.DataSet SqlExecuteDateSet(string sql, string[] paramters, params object[] values)
public System.Data.DataTable SqlExecuteDateTable(string sql, string[] paramters, params object[] values)
public int SqlExecuteNonQuery(string sql, string[] paramters, params object[] values)
public System.Data.Common.DbDataReader SqlExecuteReader(string sql, string[] paramters, params object[] values)
public object SqlExecuteScalar(string sql, string[] paramters, params object[] values)
当然，为了支持存储过程的执行，以及数据库事务，还需要提供相关的重载的API。大概的使用示例（面向SQLSERVER）如下：
DbHelper dbhelper = new DbHelper();
string sql = "delete from Citys where CityId = @id";
using (DatabaseTrans trans = new DatabaseTrans(dbhelper))
{
try
{
dbhelper.SqlExecuteNonQuery(trans, sql, new string[] { "@id" }, 1);
dbhelper.SqlExecuteNonQuery(trans, sql, new string[] { "@id" }, 2);
trans.Commit();
OutPut("ok");
}
catch (Exception)
{
trans.RollBack();
OutPut("no ok");
}
}
二、通用的ORM框架
先看如下的代码
//1、添加
xxxCase xxxCase = new xxxCase();
xxxCase.Title = "abc";
xxxCase.Content = "呵呵";
xxxCase.CaseFrom = CaseFrom.客服投诉;
xxxCase.PostUser = "huhao";
xxxCase.CreateTime = DateTime.Now;
xxxCase.CaseType = CaseType.生产环境查询;
xxxCase.Priority = CasePriority.中;
xxxCase.ReleationServices = "aaa,bbb";
xxxCase.ReleationClient = "ccc,ddd";
EntityBase.Insert(xxxCase);
//2、修改
xxxCase.ClearInnerData();
xxxCase.CaseId = 1;
xxxCase.Title = "嘿嘿";
EntityBase.Update(xxxCase);
//3、删除
xxxCase.ClearInnerData();
xxxCase.CaseId = 1;
EntityBase.Delete(xxxCase);
//4、复杂条件查询，查询大于昨天的客服投诉或者wawa关闭的问题
WhereCondition condition = new WhereCondition(
xxxCase.CaseFromColName,SqlOperator.Equal, (short)CaseFrom.客服投诉)
.And(
new WhereCondition(xxxCase.CreateTimeColName, SqlOperator.GreaterThan ,
DateTime.Now.AddDays(-1)))
.Group()
.Or(
new WhereCondition(xxxCase.CloseUserColName, SqlOperator.Equal, "wawa"));
IList<xxxCase> list = EntityBase.Select<xxxCase>(
new string[] {"Title", "PostUser"}, condition);
foreach (xxxCase item in list)
{
Console.WriteLine("{0}-{1}",item.Title,item.PostUser);
}
Console.ReadKey();
上面的代码是以面向对象（请忽略那些关于贫血模型的讨论，说上面的代码不够OO，上面的代码至少相对的面向对象，而且看起来很直观）的方式去执行一些业务，这应该比到处写SQL语句要强很多吧，而且如果这些操作内部使用的仍然是参数化查询而不是拼sql字符串的话，