基于MVVM模式的WPF应用开发：ViewModel与Model接口/抽象类困境

1. 核心问题：ViewModel的设计选择与MVVM原则合规性 #

• 优先设计全新的ViewModel类，这是最符合MVVM关注点分离原则的做法。MVVM的核心目标就是让View完全与Model隔离，只和ViewModel交互。
• 如果ViewModel实现Model层的接口或抽象类，哪怕View绑定的是接口，本质上还是间接依赖了Model的契约结构，相当于让View感知到了Model的存在，违反了严格的关注点分离。只有当Model的接口是专门为UI交互设计的（而非业务逻辑契约），这种做法才有合理性，但绝大多数场景下没必要这么做。
• ViewModel的核心职责是封装UI逻辑、暴露适合数据绑定的属性（比如实现INotifyPropertyChanged），和Model的业务契约是完全独立的两个维度。

2. Internal构造函数对可测试性的影响与解决方案 #

• 直接用internal构造函数会影响跨程序集的单元测试，因为默认情况下测试项目（一般和ViewModel不在同一程序集）无法访问internal成员。
• 确保可测试性的几种方案：
  • 在ViewModel所在程序集的AssemblyInfo.cs中添加[assembly: InternalsVisibleTo("你的测试项目名称")]，允许测试项目访问该程序集的internal成员。
  • 额外提供一个仅用于测试的public构造函数，添加明确注释说明其用途，避免业务代码误用。
  • 更规范的方式是采用依赖注入：将Model实例通过接口注入ViewModel，保持构造函数为public，同时将核心逻辑封装在内部，既满足测试需求，也符合依赖倒置原则。

3. 图形类层级的View与ViewModel设计选择 #

• 必须为每个FigureBase派生类创建对应的ViewModel包装类（比如SquareWrapper），原因如下：
  1. 严格遵循MVVM原则：View直接绑定Model会导致View依赖Model的结构，后续Model的任何修改都会直接影响View，彻底打破关注点分离。
  2. 满足UI交互需求：Model作为业务实体，通常不会实现INotifyPropertyChanged，UI修改属性后无法自动更新界面，必须由ViewModel处理属性变更通知。
  3. 隔离序列化逻辑：序列化逻辑（尤其是适配UI的格式转换、属性验证）不应放在Model中，ViewModel可以封装这些与UI相关的序列化逻辑，让Model专注于业务数据。
  4. 减少重复代码：可以创建泛型基类FigureViewModelBase<T> : INotifyPropertyChanged（其中T : FigureBase），将通用逻辑（比如Model引用、基础属性变更通知、通用序列化逻辑）放在基类中，每个派生ViewModel只需处理自身独特的属性和逻辑，大幅减少重复工作量。

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