Navigation between pages and binding of the view and viewmodel are central topics of the first two posts.
Yngve proposes to use attributes containing paths to the View on the ViewModel objects to bind the View and ViewModel. He implements methods using reflection and these attributes to look up the View given a ViewModel. Even though Yngve says in his post that "some good'ol reflection (it's not as scary as you might think)", I can't help it, I always get a bit uneasy when I see reflection and attributes containing magic strings that are used to find types. If I can avoid it I prefer to do so, and this is what this post is about.
Are there other ways to bind the View and the ViewModel while still keeping things nice and simple?
Initial architecture
Yngve builds and initial architecture as shown in the diagram below:
The App object contains a MasterViewModel object that acts as a master object keeping track of the CurrentViewModel and the CurrentPage object.
The architecture is based on an assumption that each ViewModel will have one-to-one relationship with the View.
Having only one ViewModel per View is all fine and dandy to me, but I can see that there may be scenarios where we would like to have more than one View share the same ViewModel.
Jeremy Likness in his post Model-View-ViewModel (MVVM) Explained mentions that multiple views on a single ViewModel could be beneficial if we are to implement a wizard. A single view-model shared between the wizard pages could be nice, but for the sake of simplicity I can live with 1-to-1.
Jeremy Likness also discuss the two ways to drive the creation and discovery process. One can opt to do as Yngve has done, go from the ViewModel to the View, this is referred to as ViewModel first.
Going the other direction is called, you may have guessed it already, View first.
The simple alternative
The MasterViewModel shown above has a method Goto<T> that the View will call when it wants to navigate to a different page.
E.g. in the MainPage we will have a click handler as this:
private void GoToSubpage_Click(object sender, RoutedEventArgs e) |
{ |
App.ViewModel.Goto<SubPageViewModel>(); |
} |
The goto method will find the Uri to navigate to by looking at the attribute that should be used to decorate the ViewModel class. When it has located the Uri it will use the NavigationService on the View to navigate to the Uri.
Then after the navigation has been done and the View has changed, we handle the navigated event where we see the new Uri and from the Uri we locate the matching ViewModel and set this in the view by settings its DataContext to the new ViewModel.
A simple alternative to this is to bind the ViewModel directly to the view. If the View knows what ViewModel it should bind to it can set the DataContext in its constructor.
Simply modifying MainPage.xaml.cs like this:
public partial class MainPage : PhoneApplicationPage
{
// Constructor
public MainPage()
{
InitializeComponent();
DataContext = new ViewModels.Pages.MainPageViewModel();
}
private void GoToSubpage_Click(object sender, RoutedEventArgs e)
{
NavigationService.Navigate(new Uri("/SubPage.xaml", UriKind.Relative));
}
}
And SubPage as this:
public partial class SubPage : PhoneApplicationPage
{
public SubPage()
{
InitializeComponent();
DataContext = new ViewModels.Pages.SubPageViewModel();
}
private void GoToMainPage_Click(object sender, RoutedEventArgs e)
{
NavigationService.Navigate(new Uri("/MainPage.xaml", UriKind.Relative));
}
}
Makes the need for both reflection and attributes go away. When we navigate to SubPage.xaml the View (SubPage) is automatically instantiated and the constructor of the SubPage class is called which will set the DataContext. The equivalent happens when we navigate from the SubPage to the MainPage.
This is more similar to the dependencies in the Presentation Model pattern by Fowler. MVVM is a specialization of the Presentation Model design pattern.
Although I am more happy to have a dependency in this direction, and to have done away with the reflection and the attributes, I am not to happy about the View constructing the ViewModel.
Nor am I too happy about the ViewModel being created every time we navigate to the page, it means that all ViewModel state is lost every time we navigate away from the page and back.
DataTemplates
While googling the internet for alternative solutions I saw people mentioning that they would do things similar to this:
This is supposed to bind the View and the ViewModel, but I soon figured out that this simply isn't an option for me as it would not be very different from the "Simple alternative" I just presented. Same drawbacks as already mentioned in previous discussion above that the ViewModel can't have constructor parameters. It is still the view constructing the viewmodel and still a very hard binding from the View to the ViewModel.
Finally I couldn't make it work, adding the above xaml would cause errors, and since I didn't like the solution anyway I didn't bother to try figure out what was wrong.
<phone:PhoneApplicationPage.Resources> <pages:MainPageViewModel x:Key="ViewModel"/> </phone:PhoneApplicationPage.Resources> <!--LayoutRoot is the root grid where all page content is placed--> <Grid x:Name="LayoutRoot" Background="Transparent"> <views:MainPage DataContext="{Binding Source={StaticResource ViewModel}}"/>
This is supposed to bind the View and the ViewModel, but I soon figured out that this simply isn't an option for me as it would not be very different from the "Simple alternative" I just presented. Same drawbacks as already mentioned in previous discussion above that the ViewModel can't have constructor parameters. It is still the view constructing the viewmodel and still a very hard binding from the View to the ViewModel.
Finally I couldn't make it work, adding the above xaml would cause errors, and since I didn't like the solution anyway I didn't bother to try figure out what was wrong.
MEF
Managed Extensibility Framework could provide some of the functionality that I am looking for, but sadly it seems to not be supported for Windows Phone 7 because of missing features in the base class libraries available for Windows Phone 7 applications. Damon Payne has made an unofficial MEF-for-Windows-Phone-7, but I suppose for those of us who aren't black belt Windows Phone 7 hackers yet, there may be other options that will make the learning curve a bit easier.
UltraLight
Jeremy Likness has published the Ultra Light MVVM for Windows Phone 7 micro framework.
It does View-first binding of the View and the ViewModel in addition to a number of other features.
It implements the binding using a "homegrown" servicelocator, which will be called from the View constructor.
To use UltraLight we need to download and build the 8 classes and 6 interfaces that are the Ultra Light framework.
The views now should look as this:
The BindToViewModel method is an extension method that among other things will find the ViewModel class implementing the specified ViewModel interface and then attach this to the View by setting the DataContext property of the LayoutRoot object to the located ViewModel object.
For this to work the map between ViewModel interfaces and the ViewModel classes must be registered. This will be done in the application launched event handler of the App object:
The final requirement is that all the ViewModel classes must implement an interface and they have to inherit from the framework class called BaseViewModel. The BaseViewModel class has an abstract property called ApplicationBindings which we also are required to implement.
Haven't figured out exactly why this is, but I may be using the framework wrong on this point.
In my opinion the Ultra Light framework looks promising as a starting point for doing Windows Phone 7 development. It's not too big or complex while still providing what seems to be a number of useful features.
In the figure above you can see my complete Visual Studio Solution that implements the same application as Yngve did in his blog posts. If you look at the the two views, MainPage.xaml and SubPage.xaml, you will notice that there is no code-behind. There's nothing special in the xaml file either, same as we have had in the previous examples.
All the code is in the ViewModel class
The ViewModel can be wired up with a NavigationService if we want to do navigation as shown above.
There is also a automatically generated file called AppBootstrapper. This is where we need to register our ViewModel classes. So for our little demo app that has two pages which we can navigate between we just need to register our two ViewModel classes and we are done.
There are no reference in the ViewModel to the View. I haven't dived enough into the details to explain exactly how the binding of the View and ViewModel works, but it is based on convention, and it simply works.
It of course has to be based on some sort of reflection, but I don't have to introduce any clutter like attributes or anything into my classes. Further it is driven by very natural conventions. I name the classes as I think I should do anyways and that's it. The ViewModel class is named ending with "ViewModel", which now tells both me and Calliburn that this is the ViewModel for the View that has the same name, except the ViewModel postfix. Furthermore, the Caliburn.Micro comes with a default IoC container, but the framework is configurable. If I somewhere down the line decides that I don't like the default container, I can plug in a different one.
The programming by convention is really used all over this framework, and to me this looks as having been done with great success.
If you look again at the MainPageViewModel above you will notice the GoToSubpage() method.
Then look at this snippet from the MainPage.xaml.
As you will notice, the button has the same name as the method in the ViewModel. That is all we need to do. When the user clicks this button, the GoToSubpage method in the ViewModel will be called and we can navigate to the next page, or whatever we want to do when the user clicks our button. Awesome!
The Caliburn.Micro is ViewModel-first, but it still can have multiple view for a single ViewModel. There's an eplanation of how they do it at the Caliburn.Micro codeplex site in the section Multiple Views over the Same ViewModel.
If you want to read more on Caliburn there's quite a lot more on the codeplex site for Caliburn.Micro Caliburn documentation.
A list of links to stuff I have read when researching this post:
http://www.wintellect.com/CS/blogs/jlikness/archive/tags/ultra+light/default.aspx
It does View-first binding of the View and the ViewModel in addition to a number of other features.
It implements the binding using a "homegrown" servicelocator, which will be called from the View constructor.
To use UltraLight we need to download and build the 8 classes and 6 interfaces that are the Ultra Light framework.
The views now should look as this:
public partial class MainPage : PhoneApplicationPage { // Constructor public MainPage(){ InitializeComponent();BindToViewModel<IMainPageViewModel>(LayoutRoot);}private void GoToSubpage_Click(object sender, RoutedEventArgs e) { NavigationService.Navigate(new Uri("/SubPage.xaml", UriKind.Relative)); } }
public partial class SubPage : PhoneApplicationPage
{
public SubPage()
{
InitializeComponent();
BindToViewModel<ISubPageViewModel>(LayoutRoot);
}
private void GoToMainPage_Click(object sender, RoutedEventArgs e)
{
NavigationService.Navigate(new Uri("/MainPage.xaml", UriKind.Relative));
}
}
The BindToViewModel method is an extension method that among other things will find the ViewModel class implementing the specified ViewModel interface and then attach this to the View by setting the DataContext property of the LayoutRoot object to the located ViewModel object.
For this to work the map between ViewModel interfaces and the ViewModel classes must be registered. This will be done in the application launched event handler of the App object:
private static void _RegisterViewModels()
{
UltraLightLocator.Register<IMainPageViewModel>(new MainPageViewModel());
UltraLightLocator.Register<ISubPageViewModel>(new SubPageViewModel());
}
// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
_RegisterViewModels();
}
The final requirement is that all the ViewModel classes must implement an interface and they have to inherit from the framework class called BaseViewModel. The BaseViewModel class has an abstract property called ApplicationBindings which we also are required to implement.
Haven't figured out exactly why this is, but I may be using the framework wrong on this point.
/// <summary>
/// For pages, the list of commands to bind to application bar buttons
/// </summary>
public override IEnumerable<IActionCommand<object>> ApplicationBindings
{
get { return new IActionCommand<object>[0]; }
}
In my opinion the Ultra Light framework looks promising as a starting point for doing Windows Phone 7 development. It's not too big or complex while still providing what seems to be a number of useful features.
Caliburn.Micro
Caliburn.Micro is a small framework that can be used for both WPF, Silverlight and Windows Phone 7 applications. Caliburn.Micro is a bit larger than Ultra Light, about 50 classes, but I believe it has more functionality. It comes with full source, which will by default be a part of your project. It is distributed under the MIT license. It is built by Rob Eisenberg who presented a lot of the principles that Caliburn.Micro is based on in his talk Build Your Own MVVM Framework at MIX10.
I have watched the MIX10 video, but I haven't got much time to play with this framework yet, but so far it seems to be pure awesomeness!
To create a caliburn.micro WP7 app we must first download the zip file containing three folders
In the templates folder you will find the three project templates zip files, one for each of the supported platforms. There's also a readme.txt file there describing exactly what you need to do.
After you have copied the Caliburn_Micro_WP7.zip to the right folder you can fire up Visual Studio and you should now have a new project type available, select this and you will get a project with all the required files and you are good to go.
Look mum, no code behind!
I have watched the MIX10 video, but I haven't got much time to play with this framework yet, but so far it seems to be pure awesomeness!
To create a caliburn.micro WP7 app we must first download the zip file containing three folders
In the templates folder you will find the three project templates zip files, one for each of the supported platforms. There's also a readme.txt file there describing exactly what you need to do.
After you have copied the Caliburn_Micro_WP7.zip to the right folder you can fire up Visual Studio and you should now have a new project type available, select this and you will get a project with all the required files and you are good to go.
Look mum, no code behind!
In the figure above you can see my complete Visual Studio Solution that implements the same application as Yngve did in his blog posts. If you look at the the two views, MainPage.xaml and SubPage.xaml, you will notice that there is no code-behind. There's nothing special in the xaml file either, same as we have had in the previous examples.
All the code is in the ViewModel class
public class MainPageViewModel { private INavigationService NavigationService { get; set; } public MainPageViewModel(INavigationService navigationService) { Title = "Kick Ass"; NavigationService = navigationService; } public string Title { get; private set; } public void GoToSubpage() { NavigationService.Navigate(new Uri("/SubPage.xaml", UriKind.Relative)); } }
The ViewModel can be wired up with a NavigationService if we want to do navigation as shown above.
There is also a automatically generated file called AppBootstrapper. This is where we need to register our ViewModel classes. So for our little demo app that has two pages which we can navigate between we just need to register our two ViewModel classes and we are done.
There are no reference in the ViewModel to the View. I haven't dived enough into the details to explain exactly how the binding of the View and ViewModel works, but it is based on convention, and it simply works.
It of course has to be based on some sort of reflection, but I don't have to introduce any clutter like attributes or anything into my classes. Further it is driven by very natural conventions. I name the classes as I think I should do anyways and that's it. The ViewModel class is named ending with "ViewModel", which now tells both me and Calliburn that this is the ViewModel for the View that has the same name, except the ViewModel postfix. Furthermore, the Caliburn.Micro comes with a default IoC container, but the framework is configurable. If I somewhere down the line decides that I don't like the default container, I can plug in a different one.
The programming by convention is really used all over this framework, and to me this looks as having been done with great success.
If you look again at the MainPageViewModel above you will notice the GoToSubpage() method.
Then look at this snippet from the MainPage.xaml.
As you will notice, the button has the same name as the method in the ViewModel. That is all we need to do. When the user clicks this button, the GoToSubpage method in the ViewModel will be called and we can navigate to the next page, or whatever we want to do when the user clicks our button. Awesome!
The Caliburn.Micro is ViewModel-first, but it still can have multiple view for a single ViewModel. There's an eplanation of how they do it at the Caliburn.Micro codeplex site in the section Multiple Views over the Same ViewModel.
If you want to read more on Caliburn there's quite a lot more on the codeplex site for Caliburn.Micro Caliburn documentation.
http://www.wintellect.com/CS/blogs/jlikness/archive/tags/ultra+light/default.aspx
http://blogs.msdn.com/b/davihard/archive/2010/05/10/repost-mvvm-providing-the-association-of-view-to-viewmodel.aspx
And I haven't forgotten about the Wix project template, its coming, I just had to check out WP7 first :-)
And I haven't forgotten about the Wix project template, its coming, I just had to check out WP7 first :-)
No comments:
Post a Comment