MVVM设计模式中文件解析器所属层级及项目结构优化问询

项目结构优化方案 #

推荐你按职责拆分文件夹，替换原来的粗粒度结构，规范后的结构如下：

• Views：存放所有界面文件（.xaml）和对应的后置代码，你现有的MainWindow相关代码可以保留在该目录下，将OpenFileDialog逻辑放在视图后置代码的实现完全符合MVVM规范，避免了视图层逻辑侵入ViewModel。
• ViewModels：存放所有视图模型类，负责视图和业务层的双向绑定、交互逻辑转发，你现有的MainWindowViewModel归属该层。
• Models：仅存放纯数据实体类，不包含任何业务处理逻辑，比如你代码中用到的Part类就是典型的Model层内容。
• Services：存放所有业务逻辑、工具类服务，你提到的InventorAndXACompare类、文件解析器都归属该层。
  • 可在Services下新增Parsers子目录，单独存放Inventor文件解析、XA文件解析的实现代码，和对比逻辑做物理隔离，后续如果要新增解析格式、修改解析规则时无需修改对比逻辑，可维护性更高。
• Common：存放项目通用基础代码，比如ViewModel的INotifyPropertyChanged基类、全局常量、通用扩展方法等。

常见疑问解答 #

1. InventorAndXACompare是否适合放在Models文件夹？
   不适合。Models文件夹仅存放无业务逻辑的纯数据载体，InventorAndXACompare包含文件对比、文件解析的业务逻辑，属于业务服务类，放在Services目录下更合理。

2. 文件解析器在MVVM设计模式中应该归属哪一层？
   文件解析器属于业务基础设施服务，归属服务层（对应上面的Services目录），不属于MVVM三层（View/ViewModel/Model）的任何一层，属于三层之外的业务支撑模块，上层ViewModel仅需要调用服务层暴露的方法即可，不需要感知解析的具体实现。

补充优化建议 #

• 你当前InventorAndXACompare中使用静态集合存储解析和对比结果，会存在多次调用的结果相互污染的问题，建议每次调用CompareFiles方法时都重置所有静态集合，或者改成实例类避免静态变量的副作用。
• 可以将文件解析逻辑抽象为公共接口，后续替换解析实现、新增解析格式时不需要修改上层对比逻辑，也更方便做单元测试。

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