将数据传递到数据层
本文关键字：数据 | 更新日期: 2023-09-27 18:19:30
我的模型由一个主对象组成，用户也可以添加其他各种对象。添加的对象存储在主对象及其关联子对象中包含的List<object>中。
如果这个项目是一栋房子。用户可以将存储在List<Room> RoomList中的多个Room对象添加到房子中。然后，每个Room可以在每个房间List<Furnishing> FurnishingsList 中再次添加一定数量的Furnishings
问题是如何在MVVM方法中实现这一点？当用户添加一个新对象时，我是否会将其添加到ViewModel中的ObservableCollection中，以便更新视图，同时将它添加到挂接到VM中的模型中？还是将其存储在VM中，直到发出保存或提交命令，然后将其传递给模型？
在我的示例中，我有各种编辑器（每个编辑器都是一个用户控件）。因此，用户可以在高级别上编辑房子，使用一个编辑器来添加、编辑和删除房子中的房间。在较低级别，使用不同的编辑器编辑每个房间，添加和删除Furnishings。
所以当用户"编辑"一个房间时，比如。我产生包含所述CCD_ 10的CCD_。用户添加、编辑和以其他方式操纵该房间中的家具。
在每个命令中，最好如上所述同步Model和ModelViee中的数据。或者，我直接将更改推送到Model中，并让ViewModel只在注入的Model属性上提供getter。但是，通过这种方式将对象添加到模型列表中不会更新视图。我真的必须同时将数据添加到ModelView和Model中，这样一切都处于相同的状态。
漫无边际的应用程序，努力找到一个好的方法，有人知道我在做什么吗？
我不确定是否有一个好的答案。听起来你好像在讨论如何保持一致性——你是从表示层有一个简单的直通方案，还是介入用户请求并在其中有逻辑。
如果这是事实上的问题，那么有各种因素在起作用。您更喜欢在表示层中进行验证吗？应用程序有多复杂，它需要有多大的可扩展性？是否需要在多个位置访问视图模型？
因此，考虑到所有这些，我可以告诉你我个人更喜欢如何处理这个问题（特别是你提到的添加问题）。我通常喜欢创建视图模型，用EditItemViewModel<T>或ListViewModel<T>之类的泛型来描述用户关注的问题。因此，在GUI中，会有某种绑定到ListViewModel<Room>的房间列表框。这个虚拟机显然会公开一个可观察的集合，但也会公开Add、Delete、Edit的命令。
因此，从我的角度来看，这个虚拟机将要做的表示层、视图模型化的事情是为其他GUI问题路由请求。如果您单击"添加"以添加房间，则此虚拟机负责通过命令启动对添加房间所需的任何屏幕/窗口/任何内容的请求，该虚拟机将拥有自己的虚拟机。该VM在接收到添加请求后，将生成的数据传输对象向下传递到将进行验证的域以及需要的任何域操作。我通常通过服务层来处理这个问题。现在，如果域操作成功，服务层将引发某种偶数或回调，让列表VM知道发生了更改。当这种情况发生时，列表VM会重新查询其服务，并相应地更新其可观察集合。现在，您的GUI与整个域保持一致。
我喜欢这种类型的分层方法的原因是，所有的业务逻辑都发生在GUI的"下面"，GUI不必关心这种情况。从概念上讲，GUI只是说"在这里，域层，用户想添加这个-完成所有这些，并让任何感兴趣的GUI组件知道您何时完成，以便它们可以刷新自己"。
与简单的直通方案或VM只重新公开某个模型对象上的属性的方案相比，我在这里描述的内容自然会产生一些开销。但是，就我个人而言，我认为从解耦的角度获得的优势是值得的，尤其是在扩大应用程序时。它使您能够从根本上改变域模型的内部交互，而无需更改表示层代码。
首先：View是您的DataModel的镜像，所以总是先将添加到Model，然后再考虑它是推Vm还是推View。
第二：ViewModel是连接Model和View的桥梁，但这并不意味着它的结构必须与Model的制造方式相同。如果你想向用户显示所有的子集合，你必须像属性一样公开它们，并在VM或VM中内部构建它们的parent-child关系。它们只有"原始"集合，并且在DataModel中它们之间有有效的关系。
从您描述的应用程序来看，您的视图模型层似乎不会显著修改或塑造您的模型。因此，我将使各种视图模型属性setter/getter成为封装模型对象上的简单适配器。这样，当视图模型发生更改时，您的模型将立即更新。
然而。。。如果您需要提供"取消"功能，即用户打开一个模态表单来编辑某个视图模型，但随后取消而不是确定编辑，这种简单的方法将不起作用。
提交到模型层的时间很少有什么不同，因为这通常不是一个耗时的过程。更重要的是模型状态何时持久化。这通常是由显式调用save命令触发的，该命令将模型发送到持久性服务（文件/云等）