先例举一个Dos.ORM专用实体类:
//------------------------------------------------------------------------------ // <auto-generated> // 此代码由工具生成。 // 运行时版本:4.0.30319.42000 // Website: http://ITdos.com/Dos/ORM/Index.html // 对此文件的更改可能会导致不正确的行为,并且如果 // 重新生成代码,这些更改将会丢失。 // </auto-generated> //------------------------------------------------------------------------------ using System; using Dos.ORM; namespace Model { /// <summary> /// 实体类SysMenu 。(属性说明自动提取数据库字段的描述信息) /// </summary> [Table("Sys_Menu")] [Serializable] public partial class SysMenu : Entity { #region Model private Guid _Id; private string _Url; /// <summary> /// /// </summary> public Guid Id { get{ return _Id; } set { this.OnPropertyValueChange(_.Id,_Id,value); this._Id=value; } } /// <summary> /// /// </summary> public string Url { get{ return _Url; } set { this.OnPropertyValueChange(_.Url,_Url,value); this._Url=value; } } #endregion #region Method /// <summary> /// 获取实体中的主键列 /// </summary> public override Field[] GetPrimaryKeyFields() { return new Field[] { _.Id}; } /// <summary> /// 获取列信息 /// </summary> public override Field[] GetFields() { return new Field[] { _.Id, _.Url}; } /// <summary> /// 获取值信息 /// </summary> public override object[] GetValues() { return new object[] { this._Id, this._Url}; } #endregion #region _Field /// <summary> /// 字段信息 /// </summary> public class _ { /// <summary> /// * /// </summary> public readonly static Field All = new Field("*","Sys_Menu"); /// <summary> /// /// </summary> public readonly static Field Id = new Field("Id","Sys_Menu","Id"); /// <summary> /// /// </summary> public readonly static Field Url = new Field("Url","Sys_Menu","Url"); } #endregion } }
有的朋友会问:Dos.ORM为什么把实体类搞的那么复杂?
其实,Dos.ORM的实体一点也不复杂,觉得复杂是因为没有仔细看,我们来仔细解析下这个实体类。
1、对此文件的更改可能会导致不正确的行为,并且如果重新生成代码,这些更改将会丢失?
实体类的顶部注释非常重要,强调此实体类不建议做任何修改,不能在实体类中编写任何业务逻辑代码,否则下次表新增字段重新生成实体类后,任何更改都将丢失。
2、为什么不使用这样的属性写法1?
public int Id {get; set;} public string Url {get; set;}
却要使用这样的属性写法2?
private int _Id; public int Id { get { return _Id; } set { _Id = value; } }
首选你需要知道的是前者写法1就是后者写法2的“简写”,两者在效果上没有任何区别,有区别的是扩展性。写法1无法在get中编写业务逻辑,如:
public int Id { get { if(Id <= 0){ return 1; } } }
以上代码必然使IIS程序池挂掉,死循环嘛。写法2也为了下面要讲的“OnPropertyValueChange”奠定基础。
3、为什么要使用OnPropertyValueChange?去掉OnPropertyValueChange不就可以使用写法1的最简单实体类了吗?
OnPropertyValueChange的存在是必不可少的,也是Dos.ORM的优势之一。
如一张表5个字段,在做插入或更新操作时,我们要更新其中2个字段:
var model = new Table(); model.F2 = "2"; model.F3 = "3"; Db.Update(model, d => d.Id == 1);
以上代码,由于Dos.ORM使用OnPropertyValueChange记录了你修改了F2与F3这两个字段,在生成更新sql时就会是:
UPDATE Table SET F2='2',F3='3' WHERE Id=1
而其它一些ORM,要么你需要手动调用某些方法来设置你只更新F2和F3,要么就是所有字段全更新,生成了sql:
UPDATE Table SET F2='2',F3='3',F4=null,F5=null WHERE Id=1
要么你需要先从数据库取出这个实体,修改字段后再提交数据库:
var model = Db.From<Table>().First(); model.F2 = "2"; model.F3 = "3"; Db.Update(model, d => d.Id == 1);
但这样的做法,对数据库多做了一次查询操作。
因此,OnPropertyValueChange的存在是极其重要的。不要觉得它污染了实体类,它是让实体类变得更“美好”。
4、实体类中的Method有什么用?为什么不去掉?
Method里面重写的一些方法,为Dos.ORM内部获取表相关信息带来了极大的性能提升,如获取该表的主键列表、自增字段、所有字段等等。
懂的朋友肯定能理解,空了再细细解释这块。
5、实体类中的“_”子类有什么用?
这块需要说的也较多,下次再完善此文档。
未完待续...
文章链接:http://www.iTdos.com/CSharp/201605/17195943652.html
原创说明:转载IT大师原创文章时请保留原文链接,谢谢!
转载说明:本站转载文章均标明文章来源,若本篇转载侵犯了您的权益,请联系站长删除!
交流Q群:60831381
开源组件:Dos.ORM数据库组件