WPF MVVM中Model/ViewModel设计与跨ViewModel通信咨询

基础分层设计相关问题 #

1. ObservableCollection定义位置与集合类型选择 #

• 仅在ViewModel层定义ObservableCollection即可，完全不需要在Model层重复定义。Model的本质是数据载体，只需要存储实际业务字段就行，ObservableCollection是专门为WPF UI绑定设计的、带集合变更通知的类型，属于ViewModel层专属的绑定数据源，放在Model层完全违背分层职责。
• 不要用普通List替代ObservableCollection：你的场景需要频繁增删配送单、配送项，List没有集合变更通知，每次增删后都得手动刷新UI绑定，平白多写一堆冗余代码；只有当集合加载后完全不会动态变动的时候，才考虑用List。
• 补充：别信网上"纯Model不能实现INotifyPropertyChanged"的教条，如果你需要在编辑实体属性（比如修改配送项数量）时自动同步UI，直接让Model实现属性变更通知就行，硬给每个实体再套一层ViewModel包装，除了增加代码量没有任何实际收益。

2. 数据库查询加载逻辑分层 #

• SQL操作逻辑不要写在ViewModel里，也不要写在Model里，单独抽一层轻量的数据访问层（比如Repository类） 做所有数据库操作：这层只负责接收参数、拼SQL、执行查询/写入，返回List<Delivery>/List<Item>这类纯数据集合就行，不要返回ObservableCollection，也不要掺任何UI相关逻辑。
• ViewModel只负责调用数据访问层的方法拿到结果，再把结果赋值给自己持有的ObservableCollection供View绑定。举个例子：加载配送单列表时，DeliveryViewModel调用DeliveryRepository.GetAllDeliveries()拿到List<Delivery>结果，直接new ObservableCollection<Delivery>(result)赋值给Deliveries属性就行。
• 你查到的"逻辑放Model层"的说法，针对的是充血模型里实体内置的业务计算逻辑（比如配送单算总金额），数据库访问属于独立的基础设施逻辑，单独抽层后续改SQL、换数据库都只需要动这一层，不会碰上层的VM和View代码，维护成本低很多。

3. 业务方法分层设计 #

• 按逻辑职责拆分，不要全堆在某一层：
  • 和UI无关的逻辑：比如配送单号格式校验、配送项数量不能小于0这类单实体验证规则可以写在Model里；跨实体的校验（比如新增配送单时检查单号是否重复）、数据库读写操作放在数据访问层/单独的业务服务类，不要写在ViewModel里。
  • 和UI状态、绑定数据源相关的逻辑：比如AddDelivery()方法里，操作成功后往ObservableCollection加新项、控制加载动画显示、返回错误信息给View弹提示这类逻辑，必须写在ViewModel里。
• 给你举个新增配送单的标准流程：View触发新增命令绑定到VM的AddDelivery方法→VM拿到用户输入的参数，先调用Model/业务层的校验方法验证参数合法→调用数据访问层的Insert方法把数据写入数据库，拿到新生成的配送单实体→把新实体Add到VM的Deliveries集合里→如果操作失败就把错误信息返回给View提示。全程只需要VM里持有一份ObservableCollection，完全不需要做层间集合同步，不要搞两份集合自找麻烦。

补充：跨ViewModel通信问题 #

你现在遇到的选中配送单后加载对应配送项的场景，优先用父ViewModel协调的方式实现，别上来就用事件订阅或者消息总线，过度设计只会增加后续调试成本：

• 不要让ItemViewModel直接订阅DeliveryViewModel的事件，这种强耦合的事件订阅很容易出现内存泄漏，后续改逻辑牵一发动全身。
• 最简单好维护的实现：写一个MainViewModel作为主窗口的ViewModel，持有DeliveryViewModel和ItemViewModel两个子VM的实例。在DeliveryViewModel里加一个SelectedDelivery属性，绑定到配送单列表的SelectedItem，当这个属性变更时，MainViewModel直接调用ItemViewModel的LoadDeliveryItems(SelectedDelivery.noDelivery)方法，传入当前选中的配送单号；ItemViewModel里的LoadDeliveryItems方法调用数据访问层查到对应配送项列表，再填充到自己的Items集合里就完成了。
• 消息传递/事件订阅只适合两个VM层级相隔极远、没有共同父级的场景，你这个场景是同一页面相邻的两个关联列表，用父VM协调的方式逻辑完全透明，打个断点就能排查所有问题，比隐式的消息传递靠谱得多。
• 额外提一句：你现在写的ItemViewModel还没继承ViewModelBase，记得补上，不然Items集合赋值、加载状态变更的时候UI收不到通知。

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