0

In WPF when Datagrid's CanUserDeleteRows property is set to true, then conveniently I don't need to implement deletion of elements from an underlying data structure. But it does mean that deletion mechanism is not testable as deletion can only be invoked from GUI. Or maybe it is OK because the behaviour was (presumably) well tested by Microsoft.

Is it good practice to use this default behaviour, or should I implement some delete elements in my ViewModel or Model. And if using CanUserDeleteRows=true is bad why it was provided in the first place?

Improve this question
1
  • Sometimes a paper cup is all you need. Sometimes you need a thermos flask. Neither is wrong, either option shouldn't be outright forbidden to be used; but depending on your expectations, one option might be more appropriate for you than another.
    – Flater
    Aug 18, 2021 at 13:12

1 Answer 1

Reset to default
0

The answer to your question depends entirely on whether or not you think you can trust CanUserDeleteRows to do the right thing. Can you? Have you played around with it, observed its behavior, and determined that it does what it says on the tin? There's no "right" or "wrong" or "best" way here; you have to do the thing you can live with.

For example, I would never suggest that you use this behavior to avoid validating a public API. The principle for public API's is "Never trust the client." Ergo, you still validate on the API side, even if the data grid's behavior is solid.

As to the question in your title, I'm not sure why you think this behavior is an MVVM violation. The purpose of CanUserDeleteRows is to inhibit the deletion of a row from the data grid, and that's all it does. Preventing a record from being deleted from a data grid is entirely a UI concern. That this also prevents a record from being removed from the underlying data-bound collection is a useful benefit of MVVM, and it's by design.

If you're looking for guarantees, there aren't any. As good as WPF is, I've still had to do many things that most people would consider workarounds. Is it still worth it? I think it is.

Improve this answer
6
  • Initially I wanted to clarify that my question is whether using 'CanUserDeleteRows' set to 'true' violate MVVM as this allows UI to manipulate the underlying data, but thinking about it, this is the purpose of two-way data binding that most of the data manipulation is done behind the scenes, isn't it?
    – Piotr Golacki
    Jul 30, 2021 at 14:48
  • Yep. ..........
    – Robert Harvey
    Jul 30, 2021 at 14:48
  • My confusion comes from the thing that my data is normally manipulated by the user through GUI, but sometimes in my case additional automatic processing is required which I do in my View Model, for example I need to store explicitly indices of the elements in my collection and when elements are removed I need to refresh those, so this is done in the view model, whereas deletion is done in view through data-binding, anyway I guess my question needs to be deleted
    – Piotr Golacki
    Jul 30, 2021 at 15:21
  • There are several ways in WPF to hook events that occur in the UI in order to undertake additional processing.
    – Robert Harvey
    Jul 30, 2021 at 15:27
  • I have decided to modify the DeleteCommand I use PreviewCanExecute event handler to capture the delete command , show a message box and depending on the response I either execute it or not, and mark event as handled. I am hooking up the event in XAML using CommandManager CommandManager.PreviewCanExecute="DataGrid_PreviewCanExecute" The simple messagebox logic is in dreaded code-behind which is forbidden. But in my opinion it is UI related and code-behind should be OK. It works OK and I can hook up different DataGrids if required
    – Piotr Golacki
    Aug 18, 2021 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.