看到这标题的朋友可能搞不懂到底在搞什么不过不要紧有兴趣的朋友可以先了解一下IVsSingleFileGenerator到底是用来做什么用的《实现自定义的VsSingleFileGenerator》;在里提供一个IVsSingleFileGenerator接口可以方便地为项目文件生成附属文件如刚才那文章提到的根据XML文件自动生成一个附属的C#代码文件;当然这个IVsSingleFileGenerator并不只是针对XML文件可以是随便为任何项目文件生成附属文件你只要在文件属性中设置相关CustomTools就可以了
为什么在这里我提出在代码文件的基础上再生相关的代码附属文件呢为什么不直接在原代码文件写完整就可以了;原因很简单因为手写代码是没有电脑来得快最主要一个原因是基于XML的IVsSingleFileGenerator在某方面不好所以才采用基于代码文件的方式作为代码描述模板用XML描述在现情况碰到的问题在我的数据持久层里是采用XML结合IVsSingleFileGenerator来生成相关实体类的
内容大概如下:
<SmarkDatamodelsxmlns=>
<ClassName=CustomerTable=vp_Customer>
<IDName=CustomerIDType=SystemInt/>
<PropertyName=UserNameType=SystemStringComment=用户名/>
<PropertyName=UserPWDType=SystemStringComment=用户密码/>
<PropertyName=CustomerTypeType=SystemIntComment=客户类型/>
<PropertyName=CustomerNameType=SystemStringComment=自定义名/>
<PropertyName=SexType=SystemBooleanComment=性别/>
<PropertyName=RegionType=SystemStringComment=地区/>
<PropertyName=CityType=SystemStringComment=城市/>
<PropertyName=IDCardType=SystemStringComment=身份证号/>
<PropertyName=EMailType=SystemStringComment=电子邮件/>
<PropertyName=PhoneType=SystemStringComment=电话/>
</Class>
</SmarkDatamodels>
VsSingleFileGenerator会根据XML生成以下相关实体:
///<summary>
///用户名
///</summary>
publicvirtualstringUserName{
get{
returnthismUserName;
}
set{
thismUserName=value;
thisEntityStateFieldChange(UserName);
}
}
///<summary>
///用户密码
///</summary>
publicvirtualstringUserPWD{
get{
returnthismUserPWD;
}
set{
thismUserPWD=value;
thisEntityStateFieldChange(UserPWD);
}
}
///<summary>
///客户类型
///</summary>
publicvirtualintCustomerType{
get{
returnthismCustomerType;
}
set{
thismCustomerType=value;
thisEntityStateFieldChange(CustomerType);
}
}
VsSingleFileGenerator有个不好的地方就是当主文件修改后会重新生成附属文件这样就导致你无法修改代码文件如果想为某些属性成员添加Attribute来处理一些功能基本是没办法的
如添加成员数据验证:
[NotNull]
[Length(用户名长度必须在个字符内!)]
publicstringUserName
{
get;
set;
}
即使能解决VsSingleFileGenerator生成附属文件沖突问题;但也要面对另一个问题就如何扩展XML来处理这些扩展呢添加XMLSchema扩展描述规则重写VsSingleFileGenerator代码生成部份;这样下来没多久我估计自己会疯了
实际情况添加不同Attribute来扩展辅助功能是很常见的事情就一个验证来说根据实际
情况就有很多情况类构造方式也不一样就针对这些情况来扩展XMLSchema和重写VsSingleFileGenerator带来的工作量就不用说了还有一个问题就是XML并不能提供类型编译的保证这样对XML的质量是很难保证
经过了一段时间的思考发现为什么不直接用代码作为原模板呢这样就能得到IDE的支持强在编译器的支持下保证类型输入规则的有效性以下是本人实现的简单生成模型:
interfaceIUser
{
[ID]
stringUserName{get;set;}
stringBirthDate{get;set;}
stringRegion{get;set;}
stringRemark{get;set;}
}
生成的相关代码
[Serializable]
publicclassUser:SmarkDataMappingsDataObject
{
[ID]
publicstringUserName{get{returnmUserName;}set{mUserName=value;EntityStateFieldChange(UserName);}}
privatestringmUserName;
publicstaticSmarkDataFieldInfouserName=newSmarkDataFieldInfo(UserUserName);
publicstringBirthDate{get{returnmBirthDate;}set{mBirthDate=value;EntityStateFieldChange(BirthDate);}}
privatestringmBirthDate;
publicstringRegion{get{returnmRegion;}set{mRegion=value;EntityStateFieldChange(Region);}}
privatestringmRegion;
publicstringRemark{get{returnmRemark;}set{mRemark=value;EntityStateFieldChange(Remark);}}
privatestringmRemark;
}
}
这样的话即使我们如何给属性添加Attribute都不会带来代码上的修改VsSingleFileGenerator只对属性作一个模板生成其他内容搬过来就可以了:)
WPS的排版真是没有WORD的好估计我不会用
| 上一篇：.NET三层架构解析：什么是三层架构
下一篇：利用C#实现web信息自动抓取 |
