两个视图模型之间的主从拆分：在哪里放置取消命令逻辑？
窗口的主部分包含一个 DataGrid。详细信息部分显示一个表单，允许编辑当前在主数据网格中选择的记录。 Grid 的 SelectedItem 绑定到主虚拟机。当该属性更改时，主虚拟机将创建一个新的 EditViewModel，并通过属性公开它。视图的详细信息部分使用此属性作为其 DataContext。
当实现取消等命令时，您会将它们放在主视图模型还是详细视图模型中？
详细信息视图模型负责用户与记录的交互。有人可能会争辩说，这一责任包括删除。另一方面，有人可能会认为主视图负责用户与集合的交互，并且由于删除正在修改集合，因此应将删除功能放置在其中。
谢谢你，
Ben
编辑：澄清——“实现命令”，我的意思是实现要求服务层执行所请求操作的代码。
Master section of window contains a DataGrid. Details section displays a form allowing editing of record currently selected in master's DataGrid. Grid's SelectedItem is bound to the master vm. When that property changes, the master vm creates a new EditViewModel, exposing it via a property. The details section of the view uses this property as its DataContext.
When implementing commands like cancel, would you put them in the master or details view model?
The details view model is responsible for the user's interactions with a record. One could argue that this responsibility includes deletion. On the other hand, one could argue that the master view is responsible for user interactions with the collection, and, since deletion is modifying the collection, delete functionality should be placed in it.
Thank you,
Ben
Edit: Clarification--by "implementing commands," I mean implementing the code that asks the service layer to perform the requested action.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为你的第二个论点比你的第一个论点更有力。
只是个人意见，但在我看来，删除是收藏的问题，而不是个人记录。
I think your second argument is much stronger than your first.
Just a personal opinion, but it seems to me like deletion is a concern of the collection, not an individual record.
我同意 Ian 的回答，但要补充一点，我个人认为 UI 逻辑和模型逻辑之间的区别很重要。
因此，如果此时删除主要来自 UI 列表，那么将删除放入集合 VM 中就很有意义。
一旦您开始谈论使用模型（例如从数据库中删除记录），那么记录可能就是该逻辑的正确位置。
另外，我想说的是，这种影响模型的逻辑应该被移入领域模型并移出视图模型，让虚拟机尽可能只负责 UI 逻辑，而领域模型则发展成为丰富的表达的业务逻辑。
I agree with Ian's answer but would add that I personally think the distinction between UI logic and model logic is important.
So if the deletion is at this point primarily from the UI list then putting the deletion in the collection VM makes a lot of sense.
As soon as you start to talk about working with the model (deletes of records from a database for example) then the records are probably the correct place for this logic.
Additionally I'd say that this sort of logic affecting the model should then be moved into the Domain Model and out of the View Model, leaving the VMs only responsible for UI logic as much as possible, while the Domain Model grows into a rich expression of the business logic.
每条记录只知道它自己。它甚至不应该意识到它是集合的一部分，它本身就是一个实体。主虚拟机有一个记录集合，因此它应该负责修改。
我也同意 David 的观点，即分离 UI 逻辑和业务逻辑，远离意大利面条式代码，因为如果你的业务模型发生变化，它会破坏你的视图模型代码，而且它符合 DRY 原则。
Each record only knows of itself. It shouldn't even realize that it's part of a collection, it's an entity in itself. The master VM has a collection of records, so it should be in charge of modifications.
I also agree with David on separating UI logic and business logic, stay away from spaghetti code because if your business model changes, it will break your view model code, plus it keeps with the DRY principle.