C#代碼文件生成擴展代碼文件(2)

VsSingleFileGenerator有個不好的地方就是當主文件修改後會重新生成附屬文件,這樣就導致你無法 修改代碼文件.如果想為某些屬性成員添加Attribute來處理一些功能基本是沒辦法的.

如添加成員數據驗證:

[NotNull]
[Length("5","16","用戶名長度必須在5-16個字符內!")]
public　string　UserName
{
get;
set;
}

即使能解決VsSingleFileGenerator生成附屬文件沖突問題;但也要面對另一個問題,就如何擴展XML來 處理這些擴展呢,添加XMLSchema擴展描述規則,重寫VsSingleFileGenerator代碼生成部份;這樣下來沒多 久我估計自己會瘋了....

實際情況添加不同Attribute來擴展輔助功能是很常見的事情,就一個驗證來說根據實際情況就有很多 情況,類構造方式也不一樣.就針對這些情況來擴展XMLSchema和重寫VsSingleFileGenerator帶來的工作量 就不用說了,還有一個問題就是XML並不能提供類型編譯的保證這樣對XML的質量是很難保證.

經過了一段時間的思考發現為什麼不直接用代碼作為原模板呢,這樣就能得到IDE的支持,強在編譯器的 支持下保證類型輸入規則的有效性.以下是本人實現的簡單生成模型:

[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.Data.Mappings.DataObject
{
[ID]
public　string　UserName　{　get{　return　mUserName;}

set{mUserName=value;EntityState.FIEldChange("UserName");}　}
private　string　mUserName;
public　static　Smark.Data.FieldInfo　userName　=　new　Smark.Data.FIEldInfo ("User","UserName");
public　string　BirthDate　{　get{　return　mBirthDate;}

set{mBirthDate=value;EntityState.FIEldChange("BirthDate");}　}
private　string　mBirthDate;
public　string　Region　{　get{　return　mRegion;}

set{mRegion=value;EntityState.FIEldChange("Region");}　}
private　string　mRegion;
public　string　Remark　{　get{　return　mRemark;}

set{mRemark=value;EntityState.FIEldChange("Remark");}　}
private　string　mRemark;
}
}

這樣的話即使我們如何給屬性添加Attribute都不會帶來代碼上的修改,VsSingleFileGenerator只對屬 性作一個模板生成其他內容搬過來就可以了:)

WPS的排版真是沒有Word的好...估計我不會用.