刚开始应用.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