先例举一个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大师原创文章时请保留原文链接，谢谢！
转载说明：本站转载文章均标明文章来源，若本篇转载侵犯了您的权益，请联系站长删除！
交流Ｑ群：60831381
开源组件：Dos.ORM数据库组件
