6

MVVM doesn't allow code behind and so event handling. So what's the MVVM way to be notifyed that a cell been changed ?

Erez
  • 6,405
  • 14
  • 70
  • 124
  • Seems like a legit question to me, but maybe you need to be a little more verbose with your question: what exactly don't you understand about handling that event? Do you want to know whether it should be done in the view or the viewmodel? *(Here's a hint: the ViewModel should know nothing about the DataGrid).* – slugster Sep 18 '10 at 09:55
  • @slugster - Obviously I can't use this event since MVVM doesn't allow Code Behind. So my question is what can I do instead of using this event ? – Erez Sep 18 '10 at 10:20
  • 2
    MVVM doesn't *forbid* code behind, it simply *discourages* it and gives you a pattern to attain that ideal. What exactly do you need to do once that datagrid cell is changed (your answer could dictate the approach to take)? – slugster Sep 18 '10 at 10:55

4 Answers4

1

Its a pretty legit and obvious question since there are pretty legit solutions to the problem for MVVM. I guess someone marked it down because this has probably been asked countless times before.

I know there is something built in to do this in .Net4. I am stuck at .Net3.5 so I use the CommandReference class from the WPF toolkit, to convert an event in the view to a command in a viewmodel.

NVM
  • 5,442
  • 4
  • 41
  • 61
  • The solution to the problem for MVVM is to handle the event, I think. :) – Greg D Jan 05 '11 at 21:49
  • But 'how' is the question!! You cannot add event handlers without breaking MVVM. Command reference lets you convert an event in the UI to a command in the VM. – NVM Jan 06 '11 at 05:46
0

Do you need to handle the CellEditEnding Event? Would it be a possibility to execute the code in the setter of the property which is bound to the cell?

RoelF
  • 7,483
  • 5
  • 44
  • 67
0

Since there was never an answer marked to this question; what you want is an "event to command" implementation. Basically, it captures an event of your choice and calls an ICommand implementation on your ViewModel.

Already answered here in summary (check answer by Derek Beattie).

Community
  • 1
  • 1
rumblefx0
  • 665
  • 1
  • 9
  • 22
0

"MVVM doesn't allow code behind and so event handling."

Whoops! There's the issue.

MVVM discourages code behind, it's true, but only when something can be done reasonably via Xaml. "Thou shalt not code-behind" has never been said by anyone with a clue.

Sometimes handling an event is the simplest, best way to accomplish your goal. When that's the situation, embrace it, solve your problem, and move on. Sometimes it isn't even possible to accomplish your goal in XAML. In those cases, throw the view-logic in the view's code-behind and move on.

It's far more important to maintain the architectural goals of MVVM (separation of concerns between layers) than it is to strictly abide by rules-of-thumb (such as avoiding code-behind.) If that distinction isn't made, you're missing the forest for the trees.

Greg D
  • 43,259
  • 14
  • 84
  • 117
  • Well you are right and you are wrong. If you are adding some code behind just for doing some purely UI stuff its fine. But say if the cell edit ending event is going to update something in your model (through your VM) then its a very very bad idea (IMO). – NVM Jan 06 '11 at 05:48
  • It depends on how well-suited your model is to working in a DataGrid. In a situation I have @work right now, e.g., I'm being forced to use a single-row datagrid to represent a single item. The VM isn't going to expose a collection of these items that can only ever contain one instance, that'd be a ridiculous concession on the VM side for a weird req't in the V. Rather, the V is responsible for transforming what the VM exposes as an actual application need into what it requires. – Greg D Jan 06 '11 at 12:56
  • I am not sure I understand what your scenario is. But I don't agree with the statement that "the view is responsible for transforming what the VM exposes". The View is responsible for 'showing' what the VM exposes. The VM is responsible for transforming the model. A view should only request the VM to transform things in the model based on the users request. The view has no business transforming anything in the model it is completely the VM's responsibility. And the VM exists precisely because models are not directly suited to working views (like datagridview). – NVM Jan 19 '11 at 11:32
  • And to add a little more, I'd template a user control to behave like a datagrid row rather than add a datagrid for a single item. – NVM Jan 19 '11 at 11:33
  • The ViewModel can expose a status via an enum (e.g., pass-warning-fail), but the view is responsible for transforming that enum into visual cues (colors, glyphs, whatever). This is what I mean when I say that the view is responsible for transforming what the VM exposes. – Greg D Jan 19 '11 at 13:59
  • Well then I agree. If the VM exposes something, its the view's decision to represent it whichever way it wants. But there are many instances where you will need to transform the model on cell edit ending. And thats where you need the CommandReference class. – NVM Jan 20 '11 at 08:19