I do something similar except than before step 4 I map the parameters to
properties decorated with a NavigationPropertyAttribute before calling the
Initialise.
[NavigationProperty]
public Custom SelectedCustomer{get;set;}
public void Initialize(){// Now do something and expect all the props to be
there)}
There're a few reasons why I do it this way.
- Quite often in the initialize I was just mapping those parameters to
properties, so this saves me from writing brain dead code.
- Sometimes I don't even need an Initialise method
- Often my properties are optional and I might be sending certain
parameters (e.g. for an Add I don't send a customer, but I send it for an
Edit).
- Another option would be to use ModelBinders for the Initialize method
and use a ParameterObject, but at the end I would just map it to properties
to avoid an extra step on my View Bindings (e.g. {Binding
ModelBinder.SelectedCustomer} would be {Binding SelectedCustomer}
On Wed, Nov 3, 2010 at 11:14 PM, Paul Stovell <[email protected]>wrote:
> Re: mapping views to view models, I like to use a convention to map view
> models to views (e.g., FooViewModel should expect a .xaml file named
> FooPage, FooView or FooWindow). So you shouldn’t have to store the mapping
> explicitly.
>
>
>
> In Magellan with just MVVM it goes something like this:
>
>
>
> 1. You tell an INavigator that you want to navigate, specifying:
>
> o The name of the ViewModel (“foo”)
>
> o Any parameters (customerID=36)
>
> 2. The INavigator maps it to a handler
>
> 3. The MVVM handler resolves the VM from the IOC container
>
> 4. The MVVM handler looks for an Initialize() method on the view
> mode that takes the navigation parameters – e.g.,
> public void Initialize(int customerId) {…}
>
> 5. A view is found for the ViewModel based on the conventions above
>
> 6. The view’s DataContext is set to the ViewModel
>
>
>
> The process is different if you’re using MVC controllers, but not too
> different. The VM also implements an IViewAware interface and is notified
> about view lifetime events (e.g., activated, deactivating (closing) and
> deactivated). And each step uses interfaces and strategies to make it easy
> to plug in to, like ASP.NET MVC.
>
>
>
> Paul
>
>
>
>
>
> *From:* [email protected] [mailto:[email protected]]
> *On Behalf Of *Winston Pang
> *Sent:* Wednesday, 3 November 2010 6:03 PM
> *To:* ozDotNet; ozWPF
> *Subject:* MVVM in a navigational paradigm
>
>
>
> Hey guys,
>
>
> I'm trying to apply MVVM in the WPF navigation model.
>
> I was just doing some thoughts around it
>
> Apart from the rule that the view model shouldn't know about the view, how
> would a particular view spawn another view, and push it to the navigation
> service for example? I've been playing around with some ideas of holding a
> mapping between the View and ViewModel in a global list in App. Then have
> App register against the messenger/mediator to respond to any other view
> model's wanting to spawn a new view and navigating it to it. I'm not sure if
> I'm on the right track.
>
> Would love to see how some other people have done it on here?
>
>
> Thanks.
>
>
> --Winston
>
>
> _______________________________________________
> 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
