Master-Detail Split Between Two View Models: Where to put cancel command logic?

Question

Hello,

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.