只要是有点结构化的思想,不可能项目里一个sqlHelper 满天飞 到处写 ,最终你的c#代码还是得返回一个Class 才好操作,sqlhelper, datatable这种东西也只是临时将就一下,稍微先进一点的思想会用一种结构化的思想把数据访问用面向对象的方式包装成一个层,比如普创 都把各个表名字 字段名字 专门用Columbus类定义了,普创的数据访问层确实是个糟糕的设计 通过Columns 反而增加了复杂度 ,不过好歹还有那么点意识在 好歹定义了列名 不会语句写乱了分不清东南西北,当然这个东西看你怎么权衡 ,比如我以前一直都是一个sqlHelper 满天飞 ,容我做个悲伤的表情。
分享两个以前项目刀耕火种的ORM半成品
一个是08年的时候 记得是一个李远志的朋友 推的 ,不知他是哪里抄的还是自创的,当时心智没这么成熟 没考虑到什么
面向对象设计 和通用 ,现在看到现公司的数据库访问设计 感觉好像 天下思想殊途同归。当时08年.net3.5都还刚推出 好多都是以前那种晦涩的C++开发方式 。EntityFramework也还没推出 好多都还没有结构 和面向对象这个概念在脑子里 泛型都还少有人用 ,这在当时感觉还是一种表面上蛮新进的一种结构设计方式,至少表面上充分的利用到了面向对象 和继承 ,以及泛型这些特性。这么多年我一直到今天才把翻出来看。
第一个(08年的):
开始当然是实体的定义
1 public class Clazz 2 { 3 private long classId; 4 5 public long ClassId 6 { 7 get { return classId; } 8 set { classId = value; } 9 }10 11 private string className;12 13 public string ClassName14 {15 get { return className; }16 set { className = value; }17 }18 }
接着自然是DAL层,巧妙的利用了继承两个接口的特性 ,一个接口封装了sqlhelper实现 另外一个接口 定义了相关数据访问有哪些通用方法
SQL helper封装:
1 internal abstract class AbstractDAL 2 { 3 private IDbConnection con; 4 5 private IDbTransaction tran; 6 7 #region 构造方法 8 9 protected AbstractDAL() 10 { 11 this.con = ADOHlper.CreateIDbConnection(); 12 } 13 14 protected AbstractDAL(IDbConnection con) 15 { 16 if ((this.con = con) == null) 17 this.con = ADOHlper.CreateIDbConnection(); 18 } 19 20 protected AbstractDAL(IDbTransaction tran) 21 { 22 if ((this.tran = tran) == null) 23 { 24 this.con = ADOHlper.CreateIDbConnection(); 25 } 26 else 27 { 28 this.con = this.tran.Connection; 29 if (this.con == null || this.con.State != ConnectionState.Open) 30 throw new ArgumentException("非法的事务参数,其连接必须存在且处于被打开状态"); 31 } 32 } 33 34
No comments:
Post a Comment