在viewmodel中将通用字段放入基类供子类继承是否是不良实践？

这种做法并非绝对的不良实践，是否适用完全取决于你的实际业务场景，相关资料中提及的风险本质是「继承滥用」带来的后续维护问题，以下是具体的利弊分析和落地建议：

基类继承方案的优势 #

• 完全符合DRY（不要重复自己）原则，3个通用字段的属性定义、校验规则、默认值、转换逻辑仅需编写一次，后续统一修改也只需要调整基类一处
• 对于字段逻辑完全无差异化的场景，开发和维护成本都更低，现有框架的字段校验、绑定逻辑也都可以正常兼容

该方案被称为不良实践的核心原因 #

继承带来的强耦合特性会限制后续的扩展灵活性：

• 一旦后续某一个页面的通用字段出现差异化需求，比如某字段校验规则调整、需要删除其中某一个字段，你会陷入两难：修改基类会影响所有继承的子类，不修改基类就需要在子类中覆写逻辑，反而会产生更多冗余代码，甚至出现隐式的逻辑冲突
• 违背「组合优于继承」的设计原则：ViewModel的本质是单个页面的视图数据载体，多个页面恰好有几个相同字段，不代表这些ViewModel存在严格的「is-a」继承关系，强行用基类绑定会违背本身的语义，同时Java、C#这类单继承语言也会因此失去继承其他基类的可能性

实际落地建议 #

你可以根据业务特性选择适配的方案：

• 如果这3个字段是业务上强绑定的全局通用属性，所有用到的页面100%不会出现差异化调整，比如全局用户ID、租户标识、请求来源这类完全固定的字段，直接用基类继承完全可行，不需要强行纠结不良实践的说法
• 如果这3个字段只是当前恰好多个页面共用，后续存在调整可能，或者未来会有其他不同的通用字段组合，更推荐用组合的方案：把3个字段封装为独立的可复用类，在需要用到的ViewModel中引入该类的实例即可，既消除了重复代码，也保留了足够的扩展灵活性。示例代码如下：

// 封装通用字段的独立类
public class CommonPageMeta
{
    [Required]
    public long UserId { get; set; }
    [StringLength(16)]
    public string TenantCode { get; set; }
    public int Source { get; set; }
}

// 页面对应的ViewModel，用组合代替继承
public class GoodsListViewModel
{
    public CommonPageMeta CommonMeta { get; set; }
    // 页面自有属性
    public List<GoodsItem> GoodsList { get; set; }
}

补充：如果觉得每次访问字段都要多写一层.CommonMeta比较麻烦，你可以在ViewModel中写几个简单的代理属性映射内部的通用字段实例，不会增加太多代码量。

内容的提问来源于stack exchange，提问作者Blingers