Hi Greg, I agree with Winston. It sounds like your controller is in fact a view model. I see no problem with it being defined the way it is, however I do get worried about service locators. :) And you have a problem with lifetime as you said, this could be part of it.
A strategy you might want to consider: 1) Consider injecting your singleton objects into your ViewModels (we'll refer to them as this from now on for clarity) rather than a service locator 2) Introduce an IOC container to do the dependency injection for you 3) For cross ViewModel communication, consider an event aggregator such as that found in Prism or Ninject. These usually use weak references to bind publishers and subscribers together such that if one view model goes out of scope, the event aggregator will also "let go" of the vm, letting it get garbage collected I have some basic code for a project I just started a few days ago which has: - Basic MVVM structure (no frameworks here though, all hand rolled) - A navigation service (think of this as an application controller focused purely on navigating between views) which is a singleton yet is injected into all view models, and is responsible for assigning the view model as the datacontext on the view that is navigated to - IOC container (Autofac) o Auto registration of views and view models, and navigation routes based on view name If you want it, let me know the best email and I'll send it. You can also check out Magellan<http://www.paulstovell.com/magellan>. It started as an MVC framework for WPF but has grown into so much more. Just reading the articles and documentation on that site will give you good guidance on how to approach MVC in WPF (If that's your goal). It also works very well with IOC. And you'll find a very sup'ed up navigation controller there as well. Paul is obviously on this list and can help you with it if needed. Cheers, Steven Nagy Readify | Senior Consultant M: +61 404 044 513 | E: [email protected]<sip:[email protected]> | B: azure.snagy.name<http://azure.snagy.name/> From: [email protected] [mailto:[email protected]] On Behalf Of Winston Pang Sent: Tuesday, 27 July 2010 1:50 PM To: ozWPF Subject: Re: Commands to the controller Hey Greg, From reading that, it looks like your controllers are in fact the VM. I assume you have a base controller (base VM) that holds common properties to access all your services. I'm definitely no MVVM guru, but from the looks of things the fundamental aspect to it all is that the view (the actual XAML) shouldn't know about it's underlying controller/VM, as to when you should wire the view up with it, is another thing which obviously fits differently depending on your requirements. Most commonly I've seen people just assign the DataContext in the constructor for the actual XAML code behind. Cheers, Winston On Tue, Jul 27, 2010 at 9:04 AM, Greg Keogh <[email protected]<mailto:[email protected]>> wrote: But the more you talk about this, it seems to me you have a view model, not a controller. Maybe I am missing something... anyway I find that MVVM fixes all those binding issues. You could be right. I might have only partly (or incorrectly) implemented MVVM due to bias from years of using VM. My controllers might be living in the wrong place and have the wrong lifetime. This is the structure I have: I have a set of "service classes" that manage logging, config, settings, messaging, emailing, etc that are prepared when the app starts. They live as long as the app and are accessible anywhere thanks to a singleton "service locator" that holds them all. (CAB does this) Each View (UserControl) has a corresponding controller class that is defined in the view Resources (as in my sample code yesterday). The controllers all have references to the services and other common stuff. The controllers all talk to each other via simple message broadcasts. Views bind properties and events to the controller. Because I'm having trouble with the "lifetime" of the view and its controller, I suspect I have a design problem with the way the controller is a resource of the view. What is the recommended MMVM way of doing this? Where do the controllers live and when are they constructed? When are they bound to their view? Can someone point me to a minimal MVVM sample that shows the recommended way of structuring the MVVM pieces? I'll keep looking for one in the meantime. Cheers, Greg _______________________________________________ ozwpf mailing list [email protected]<mailto:[email protected]> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
