為什麼在這裡我提出在代碼文件的基礎上再生相關的代碼附屬文件呢
內容大概如下:
<SmarkDatamodels xmlns=
<Class Name=
<ID Name=
<Property Name=
<Property Name=
<Property Name=
<Property Name=
<Property Name=
<Property Name=
<Property Name=
<Property Name=
<Property Name=
<Property Name=
</Class>
</SmarkDatamodels>
VsSingleFileGenerator會根據XML生成以下相關實體:
/// <summary>
/// 用戶名
/// </summary>
public virtual string UserName {
get {
return this
}
set {
this
this
}
}
/// <summary>
/// 用戶密碼
/// </summary>
public virtual string UserPWD {
get {
return this
}
set {
this
this
}
}
/// <summary>
/// 客戶類型
/// </summary>
public virtual int CustomerType {
get {
return this
}
set {
this
this
}
}
VsSingleFileGenerator有個不好的地方就是當主文件修改後會重新生成附屬文件
如添加成員數據驗證:
[NotNull]
[Length(
public string UserName
{
get;
set;
}
即使能解決VsSingleFileGenerator生成附屬文件沖突問題;但也要面對另一個問題
實際情況添加不同Attribute來擴展輔助功能是很常見的事情
經過了一段時間的思考發現為什麼不直接用代碼作為原模板呢
強在編譯器的支持下保證類型輸入規則的有效性
[Table]
interface IUser
{
[ID]
string UserName { get; set; }
string BirthDate { get; set; }
string Region { get; set; }
string Remark { get; set; }
}
生成的相關代碼
[Table]
[Serializable]
public class User:Smark
{
[ID]
public string UserName { get{ return mUserName;} set{mUserName=value;EntityState
private string mUserName;
public static Smark
public string BirthDate { get{ return mBirthDate;} set{mBirthDate=value;EntityState
private string mBirthDate;
public string Region { get{ return mRegion;} set{mRegion=value;EntityState
private string mRegion;
public string Remark { get{ return mRemark;} set{mRemark=value;EntityState
private string mRemark;
}
}
這樣的話即使我們如何給屬性添加Attribute都不會帶來代碼上的修改
From:http://tw.wingwit.com/Article/program/net/201311/12332.html