I personally don't think using a command would make it more or less MVVM. I don't think commands are adding any value. Some would say they make it explicit that something is a UI Command, for me a public method is just as explicit. In terms of testability and separation of concerns, I think a command actually does just the opposite than helping. In terms of line of code (a metric we probably shouldn't be concern about anyway), it's pretty much the same, although IMO the Codebehind approach is clearer.
The only part where I would probably agree with the purists is that we run the risk to accidentally end up with too much logic in the UI. On Tue, Nov 9, 2010 at 2:34 PM, Winston Pang <[email protected]> wrote: > Sometimes I am tempted to write code like that, but I'm afraid some MVVM > purist or some pedantic bastard will give me a purist talk. > > > > On Tue, Nov 9, 2010 at 2:33 PM, Miguel Madero <[email protected]> wrote: > >> >From codebehind yes. >> >> Let's assume you have a button in your listBox's datatemplate. >> >> public OnDeleteButtonClick(o...e..){ >> var orderToDelete = ((Button)o).DataContext; >> var viewModel = (MyViewModel)DataContext; >> viewModel.DeleteOrder(orderToDelete); >> } >> >> I tend to have a property that gives me the ViewModel just to remove the >> cast from my code. >> >> >> On Tue, Nov 9, 2010 at 8:47 AM, Winston Pang <[email protected]>wrote: >> >>> Oh right, as in, casting DataContext to the respective VM and invoking it >>> with respective params? >>> >>> >>> On Tue, Nov 9, 2010 at 9:42 AM, Miguel Madero <[email protected]>wrote: >>> >>>> I rarely have to pass parameters. The CallMethodAction doesn't have this >>>> option. I prefer parameterless methods and databind to properties to give >>>> my >>>> VMs the extra context. In cases where this isn't possible I do it from code >>>> behind. I guess it would be really simple to write a CallMethodAction that >>>> takes a parameter or parameter list if you need this functionality. Since >>>> this isn't a common task for me, it has been simpler to write an event >>>> handler and directly call the method. >>>> >>>> >>>> >>>> >>>> On Mon, Nov 8, 2010 at 7:45 PM, Winston Pang <[email protected]>wrote: >>>> >>>>> Nice, that's interesting, never seen that one, I hate having to declare >>>>> ICommand's it's such a hassle just to wire something up. >>>>> >>>>> How do you pass args/params with CallMethodAction >>>>> >>>>> >>>>> On Sun, Nov 7, 2010 at 8:34 PM, Miguel Madero >>>>> <[email protected]>wrote: >>>>> >>>>>> BTW I love the CallMethodAction in Blend so I don't have to define >>>>>> Command in my ViewModels. It feels more POCOish. Just a public method. >>>>>> If I >>>>>> need the IsEnabled I just add a property and bind it to either IsEnabled >>>>>> or >>>>>> Visibility. >>>>>> <rant> >>>>>> Commands are just too messy and feels like leaking view concerns into >>>>>> my VMs. Just for the same reason I don't expose properties of type >>>>>> Visibility, I don't like exposing ICommand. >>>>>> Setting purity aside, it's just too much work, create another property >>>>>> that delegates on your method, initialise it in the constructor, then >>>>>> find >>>>>> ways to actually be able to call that from code... naaa. That's just >>>>>> messy. >>>>>> </rant> >>>>>> >>>>>> >>>>>> On Sun, Nov 7, 2010 at 7:26 PM, Miguel Madero >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> +1 for Blend Triggers and Actions >>>>>>> +1 for Code Behind for uncommon scenarios as a second option. >>>>>>> >>>>>>> On Tue, Nov 2, 2010 at 2:36 PM, Paul Stovell < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> There is an Expression Blend trigger action that can invoke a >>>>>>>> command IIRC. That’s probably the easiest way. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Caliburn also has a nice approach of mapping an event to a ViewModel >>>>>>>> method via an attached property – something like <Button >>>>>>>> cal:Message.Attach=’[Event MouseOver] = DoSomething()’ /> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Personally, if there’s no command out of the box and it’s not a >>>>>>>> common scenario, I’m quite happy to write a plain old event handler and >>>>>>>> invoke the method on the VM manually. There’s nothing wrong with a >>>>>>>> little >>>>>>>> code behind. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* [email protected] [mailto: >>>>>>>> [email protected]] *On Behalf Of *Greg Keogh >>>>>>>> *Sent:* Tuesday, 2 November 2010 2:31 PM >>>>>>>> *To:* 'ozWPF' >>>>>>>> *Subject:* Events to command binding >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Some have scoffed when I expressed dismay at the artifice that >>>>>>>> creates binding. I’ve just discovered that I’m wasting hours of time >>>>>>>> converting events into commands. For example, iIt took me an hour to >>>>>>>> find a >>>>>>>> piece of sample code that converted KeyDown on TreeView nodes to a >>>>>>>> binding >>>>>>>> (found >>>>>>>> HERE<http://stackoverflow.com/questions/612966/keyboard-events-in-a-wpf-mvvm-application>), >>>>>>>> but it needed delicate merging with existing ICommand processing >>>>>>>> classes I >>>>>>>> use. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I estimate that 50% of the time I spend writing WPF apps is wasted >>>>>>>> trying to follow MVVM and bind the control XAML to my controller >>>>>>>> class. It >>>>>>>> seems that every other man and his dog who is trying to follow the MVVM >>>>>>>> pattern as well has created untold amounts of confusing and >>>>>>>> conflicting code >>>>>>>> for the purpose. I’m sick of searching for and finding jumbles of code >>>>>>>> that >>>>>>>> I have to tidy up and include in my projects. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I feel compelled to write a small infrastructure that allows >>>>>>>> event-to-command binding in a generalised way, but I’ll bet it’s been >>>>>>>> done >>>>>>>> already (multiple times and in multiple ways). Has anyone got any >>>>>>>> suggestions or comments on this? Surely I’m not the first person in the >>>>>>>> world to have stumbled across these hurdles. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> MVVM would be wonderful if all of the wiring was just built-in. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Greg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>> ozwpf mailing list >>>>>>>> [email protected] >>>>>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Miguel A. Madero Reyes >>>>>>> www.miguelmadero.com (blog) >>>>>>> [email protected] >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Miguel A. Madero Reyes >>>>>> www.miguelmadero.com (blog) >>>>>> [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> ozwpf mailing list >>>>>> [email protected] >>>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> ozwpf mailing list >>>>> [email protected] >>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>>> >>>>> >>>> >>>> >>>> -- >>>> Miguel A. Madero Reyes >>>> www.miguelmadero.com (blog) >>>> [email protected] >>>> >>>> _______________________________________________ >>>> ozwpf mailing list >>>> [email protected] >>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>> >>>> >>> >>> _______________________________________________ >>> ozwpf mailing list >>> [email protected] >>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>> >>> >> >> >> -- >> Miguel A. Madero Reyes >> www.miguelmadero.com (blog) >> [email protected] >> >> _______________________________________________ >> ozwpf mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >> >> > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > > -- Miguel A. Madero Reyes www.miguelmadero.com (blog) [email protected]
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
