刚开始应用.NET开发数据库访问代码,实体层的手工编码是一个相对麻烦而又重复的工作。增加数据库字段,需要添加实体层类型属性,其次还要修改数据库读写代码。在项目初试阶段,这种变动太频繁了,于是根据一些项目的特性,设计了如下的代码生成器,以减少没有技术含量的基础代码生成工作。
下面以(localhost)上面的Northwind为例子,来看看如何应用它。
在服务器停靠窗体中,添加新的数据库,选择Employees表,生成它的Model类型的代码,也就是实体层。
using System; namespace BusinessEntity { /// <summary> /// 实体类EmployeesEntity /// </summary> public class EmployeesEntity { public EmployeesEntity() { } private int _employeeid; private string _lastname; private string _firstname; private string _title; private string _titleofcourtesy; private DateTime _birthdate; private DateTime _hiredate; private string _address; private string _city; private string _region; private string _postalcode; private string _country; private string _homephone; private string _extension; private byte[] _photo; private string _notes; private int _reportsto; private string _photopath; public int EmployeeID ...... }
部分代码如下图所示的,对每个字段添加下划线,再首字母大写生成对应的属性。网上常称这是个贫血的类型定义,没有适当的方法行为。
再选择DAL数据访问代码,选择基于Param类型的,或是基于SQL方式的代码,生成的代码例子如下
using System; using System.Data; using System.Text; using System.Collections.Generic; using Microsoft.Practices.EnterpriseLibrary.Data; using Microsoft.Practices.EnterpriseLibrary.Data.Sql; using System.Data.Common; namespace Service { /// <summary> /// 数据访问类EmployeesDAL。 /// </summary> public class EmployeesDAL { public EmployeesDAL() {} /// <summary> /// 是否存在该记录 /// </summary> public bool Exists(int EmployeeID,string LastName) { StringBuilder strSql=new StringBuilder(); strSql.Append("SELECT COUNT(1) FROM Employees"); strSql.Append(" WHERE EmployeeID="+EmployeeID+" and LastName="+LastName+" "); Database db = DatabaseFactory.CreateDatabase(); DbCommand dbCommand = db.GetSqlStringCommand(strSql.ToString()); int cmdresult; object obj = db.ExecuteScalar(dbCommand); if ((Object.Equals(obj, null)) || (Object.Equals(obj, System.DBNull.Value))) { cmdresult = 0; } else { cmdresult = int.Parse(obj.ToString()); } if (cmdresult == 0) { return false; } else { return true; } } ------ }
最后,生成业务接口,以封装上面的数据访问代码。
using System; using System.Data; using System.Collections.Generic; using BusinessEntity; namespace Service { /// <summary> /// 业务逻辑类EmployeesService /// </summary> public class EmployeesService { private readonly EmployeesDAL dal=new EmployeesDAL(); public EmployeesService() {} #region 成员方法 /// <summary> /// 是否存在该记录 /// </summary> public bool Exists(int EmployeeID,string LastName) { return dal.Exists(EmployeeID,LastName); } ...... }
在2009年,我写过一篇文章,指出代码生成器配合一种小项目结构,以快速应用开发。请参考文章《一种小项目开发结构》,来了解这种结构。我截取一个图,简单的概括一下它的基本结构
设计三个层,实体层 BusinessEntity,数据访问层DataProvider,服务接口层Service,最后是界面层Web应用程序。
ASP.NET Factory代码生成器能胜任上面的工作,为你减轻大量敲写重复代码的工作量。
在2010年的时候,接触到ORM,并且应用到项目中去。ORM项目有自己的代码生成器,再加上自己对模板生成有了新的理解和认识,这个代码生成器就停止维护,一直未进行过修订,所以如果所下载的源码中有Bug,请自行调试解决。
这种代码生成器有一定的优势,弊端也有,我列举几条,供您作出增强方面的参考
1 如果需要改动生成的代码格式,需要修改代码,重新编译,这会带来新的bug。
2 当时只考虑了SQL Server,没有对Access,Oracle,MySQL等流行的数据库进行编码,也没有留下扩展的接口。
3 命名规则固定到代码中,没有应用配置选项。被生成的实体名,数据访问DAL方法名,命名空间,都写死到代码中,如果需要修改,请自行查找出处。
4 没有批量代码生成的功能。如果需要对同一个数据库的所有表生成所有的实体访问代码,则无法做到。
5 没有同时生成VB和C#两种代码。合理的情况下,应该提供同时生成VB和C#两种格式的代码,像CodeDom那样。微软自己的窗体设计器,就是应用CodeDom,可生成VB或C#的两种格式的代码,而只需要一写编写,维护一套代码。
所有源代码下载地址 http://epn.codeplex.com