C# 将数据传递到数据层

我的模型由一个主对象组成，用户也可以添加其他各种对象。添加的对象存储在主对象及其关联子对象中包含的

列表中

所以如果这个项目是一栋房子。用户可以将存储在
列表RoomList
中的许多
房间
对象添加到房屋中。然后，每个
房间
都可以在每个房间中再次添加一些
家具

问题是如何在MVVM方法中实现这一点？当用户添加新对象时，我是否将其添加到ViewModel中的
ObservableCollection
，以便更新视图，同时将其添加到连接到VM的模型中？还是将其存储在VM中，直到发出保存或提交命令，然后将其传递给模型

在我的示例中，我有各种编辑器（每个编辑器都是用户控件）。因此，用户可以在较高级别上编辑房屋，使用一个编辑器添加、编辑和删除房屋中的房间。在较低的级别上，使用不同的编辑器编辑每个房间，添加和删除家具

因此，当用户“编辑”一个文件室时，可以这样说。我生成一个
EditRoomModelView
，其中包含所述
房间
。用户添加、编辑或以其他方式操纵该房间中的家具

在每个命令中，最好如上所述同步模型和ModelViee中的数据。或者我直接将更改推入模型，让ViewModel只提供注入模型属性的getter。但是，通过这种方式将对象添加到模型列表不会更新视图。我必须同时将数据添加到ModelView和模型中，这样所有内容都处于相同的状态

对于漫无边际，努力寻找一个很好的方法，任何人都能理解我的意思吗？
首先：
视图
是你的
数据模型
的镜像，所以总是首先添加到
模型
，并且只有在思考之后，如果它推动
虚拟机
或
视图

第二：
ViewModel
是连接您的
Model
与
View
的桥梁，但并不意味着它必须以与制作
Model
相同的方式构造。如果要向用户显示所有子集合，必须像属性一样公开它们，并在
VM
或
VM
中内部构建它们的
parent-child
关系集合，并在您描述的应用程序的
数据模型
中在它们之间建立有效的关系听起来您的视图模型层并没有显著地修改或塑造您的模型。因此，我将使各种视图模型属性setter/getter成为包装模型对象上的简单适配器。这样，当视图模型更改时，模型将立即更新

然而。。。如果您需要提供“取消”功能，即用户打开一个模式表单以编辑某些视图模型，但随后取消而不是确定编辑，则此简单方法将不起作用

提交到模型层的时间很少会有很大的不同，因为这通常不是一个耗时的过程。更重要的是当模型状态被持久化时。这通常是由显式调用save命令触发的，save命令将模型发送到持久性服务（文件/云等…）
我不确定是否有一个好的答案。听起来你好像在争论如何保持一致性——你是否有一个来自表示层的简单传递方案，或者你是否介入用户请求并在其中包含逻辑

事实上，如果这是一个问题，那么有各种因素在起作用。您喜欢在表示层中进行验证吗？应用程序有多复杂，需要多大的可扩展性？是否需要在多个位置访问视图模型

因此，考虑到所有这些，我可以告诉你我个人更喜欢如何处理这个问题（特别是你提到的添加问题）。我通常喜欢创建视图模型来描述用户对泛型的关注，例如
EditItemViewModel
或
ListViewModel
。因此，在GUI中，将有某种类型的文件室列表框绑定到
ListViewModel
。这个VM显然会公开一个可观察的集合，但也会公开用于添加、删除和编辑的命令

因此，从我的角度来看，这个虚拟机将要做的表示层、视图模型的工作是为其他GUI问题路由请求。如果您单击“添加”以添加房间，则此VM负责通过命令为房间添加所需的任何屏幕/窗口/任何内容启动请求，该请求将具有自己的VM。此VM在接收到添加请求后，会将生成的数据传输对象向下传递到将进行验证的域以及任何需要的域操作。我通常通过服务层来处理这个问题。现在，如果域操作成功，服务层将发出某种偶数或回调，让列表VM知道有更改。当这种情况发生时，列表VM重新查询其服务并相应地更新其可观察集合。现在，您的GUI与整个域保持一致

我支持这种分层方法的原因是，所有业务逻辑都发生在GUI的“下方”，GUI不必关心这种情况。从概念上讲，GUI只是说“在这里，域层，用户想要添加这个-做所有这些，并让任何感兴趣的GUI组件知道您何时完成了，以便它们可以刷新自己”

我在这里描述的内容自然会产生一些开销，与简单的直通方案或VM只是重新公开某个模型对象上的属性的方案相比。但是，就我个人而言，