新项目中与Team的成员讨论了一下关于数据访问层的整理和重构,基于对原有的访问层的一些不满意:主要是每个方法都要自己手写SQL语句这一状况,我提出建议是使用O/R Mapping工具,现在这类工具有如过江之鲫,但比较好用也就是那几个:nHibernate,iBatis.Net,nObject。但这一提议并没有收到效果,Team里的成员有些没有接触过这些框架,且害怕学习曲线过长,无法在项目的预期时间内完成任务,只得作罢。
后来与他们聊了聊,大家的想法是:如果能一个操作器,只要简单地将我们定义的实体类塞进去,而访问层就能完成,那就是最理想的情况——即,DAL层都不愿一个个写方法了。是人就想要偷偷懒,这也是人类进步的动力嘛:)况且程序员本来就是最懒的一群人,宁愿多用些脑细胞,也不愿多写一行代码,对此深表理解~ 说白了,要做到DAL简单的几行代码搞定,那也就是自己开发O/R Mapping工具,不是多牛,至少是初级的,能更高抽象一些重复代码工作的框架。
自然,这个光荣而艰巨的任务落在了本人的头上。怎么下手呢?首先跳入脑海的就是“反射”,无非就是,将数据库中的表一字不差的按列生成各个实体,列和实体中的字段名称相同,用反射来生成一些SQL句子,通过反射获取的字段属性PropertyInfo.GetValue()方法来做参数的绑定(SqlParameter,防注入).,最后将这些方法提取出来,结合Ado.Net方法,给DAL层提供调用。
有了思路,就可以动手了。
假设有一张这样的表:TB_NEWS,其中id列既为主键又是自增列(自增列在生成通用代码,需要注意,必须进行处理)
那么,定义一个实体类dtoNews与其对应:
namespace IndieFacade
{
public class dtoNews
{
public dtoNews() { }
private int m_id;
private string m_author;
private DateTime m_pubtime;
private string m_contents;
private int m_reads;
private string m_tags;
private string m_title;
private string m_summary;
/// <summary>
/// ID
/// </summary>
public int id
{
get { return m_id; }
set { m_id = value; }
}
/// <summary>
/// 标题
/// </summary>
public string Title
{
get { return m_title; }
set { m_title = value; }
}
/// <summary>
/// Summary
/// </summary>
public string Summary
{
get { return m_summary; }
set { m_summary = value; }
}
/// <summary>
/// Author
/// </summary>
public string Author
{
get { return m_author; }
set { m_author = value; }
}
/// <summary>
/// Tags
/// </summary>
public string Tags
{
get { return m_tags; }
set { m_tags = value; }
}
/// <summary>
/// Reads
/// </summary>
public int Reads
{
get { return m_reads; }
set { m_reads = value; }
}
/// <summary>
/// Contents
/// </summary>
public string Contents
{
get { return m_contents; }
set { m_contents = value; }
}
/// <summary>
/// 发布时间
/// </summary>
public DateTime PubTime
{
get { return m_pubtime; }
set { m_pubtime = value; }
}
}
}
然后,我写了这样一个DbCommon类,用于处理一些通用的方法,当然,只是试验了几个简单的CRUD方法:
再写一个针对dtoNews实体与TB_NEWS表进行操作的DAL类:ManagerNews,调用DBCommon类中的方法进行这样的操作,将数据实体转换为一条数据记录:
最后到客户端(例如WEB上的.aspx页面)就变得非常的轻松了:
这个框架还很稚嫩,还只是解决了一两个如何偷懒的问题,至少在本人可怜的512内存机器上,性能堪忧,以后再慢慢改进吧。