I am looking at creating my own development framework for Silverlight as an exercise in understanding MVVM and approaching some concepts that are still unknown to me. So there are a couple of issues:
1)
I am thinking about the following problem: I create custom/user controls that contain buttons/hyperlinks that would essentially change the current view.
How would something like that be bound following the MVVM paradigm. How would the view-model capture that information, such that the destination Uri is not hardcoded in the control or the view?
2)
It seems that the view-model should be responsible with announcing a higher level entity -- caliburn and prism call it Shell -- that a new view needs to be loaded and which one.
How would this mechanism work?
You may want to look at the navigation framework in SL4 it may make you rethink how to accomplish many things.
but 1) You define a Frame to somewhere in your application and bind its source to your usercontrols, which inherit their datacontex from their new parent.
Related
I think I have a pretty good understanding of the MVVM design model, however I have a quarm with it in regards to WPF, Command bindings and how we are meant to use them.
To bind commands to the XAML directly we are meant to implement the ICommand interface within the ViewModel. Now, the ICommand interface is part of the PresentationCore.DLL, which, correct me if im wrong is part of WPF not the base .NET framework.
Isnt the whole point of the ViewModel and Model that it should be totally UI independant? For example, if I implement ICommand in my ViewModel and use it as a data context in order to bind commands from the XAML, isnt my ViewModel then dependant on the WPF frame work (in particular the PresentationCore.Dll).
What I mean is, if I was to go and try to use my Models and ViewModels in lets say a Windows Forms environment, I would have to reference the PresentationCore.DLL even though I shouldnt need it because im using Windows Forms not the WPF framework.
This seems a bit odd to me, am I missing something here? Is there another way I should be doing it to keep my Model and ViewModel totally UI and UI Framework independant, but still be able to utilise the Command binding in XAML?
Thanks in advance!
I also had this kind of problem but not in wpf but in POCO classes. What i did was I created two partial classes in two different assemblies. Like you create one partial class which is not presentationcore.dll dependent in your VM project and create its partial class in another assembly(say WPFVM) which implements ICommand stuff. Now for Winforms stuff add only VM project reference to View project and for WPF stuff add references of both VM and WPFVM to the View project. I hope this will help.
The point of MVVM is to have the view just be a view, and nothing more. Putting ICommands into the view model helps this as it pulls the code away from the view. Where you will run into problems is if you have to access something on the view that is not a dependency property, which means you can not bind to it.
In my opinion MVVM is very popular with the WPF, Silverlight because it naturally fits into it. The data binding concept in the XAML allows the Views & ViewModels to be bridged using a single property which is the DataContext. As no longer your logic is tied to controls, you get better testability, design-code separation and maintainability. You may be able to implement the MVVM pattern in other places also, but in WPF and Silverlight, it fits so easily due to its data and command binding support. I have read somewhere that, Don't take patterns religiously. They were made to make your life simpler rather than giving you more problems while following it. For Winforms i think there are better patterns, If you are focusing in reusing the business logic, move them out of your ViewModels to seperate classes something like serviceproviders or serviceagents and share them between your Winforms and WPF apps.
This has changed in .NET 4.5 compare
.NET Framework 4.5
.NET Framework 4
I have a silverlight bing map application. I am using the MVVM pattern with PRISM.
The bing map has a "BoundingRectangle" property that is not available in XAML, but it is available via code behind. Of course this does me no good since I need the data in my viewmodel which doesn't have access to the View's code behind (nor do I want to add it, since I'd really like to try to not use the view's code behind if possible).
Normally, you would do a two way bind to a viewmodel property. The Bing map will surface BoundingRectangle for layers, but not for the base map (that I can find).
I'm not looking for a hack here, just wondering what the best practices or convention for getting data out of a view to a viewmodel that isn't "bindable".
Thanks!
Databinding in Silverlight is just a framework feature that automatically synchronizes data between your view and your view model (if you are following the MVVM pattern). However, there is nothing wrong with doing this yourself!
The two main advantages of the MVVM pattern (other than the usual separation of concerns that most UI patterns provide) are:
It aids unit testing, the View Model can be exercised from your unit test code without a view present.
It helps the developer / designer workflow, reducing the files shared between the designer and developer.
In my experience, having a small amount of code-behind that 'assists' the binding framework does no hard at all!
You can use techniques such as attached behaviours to wrap this code up, but often this just results in a cosmetic improvement.
CraigF,
you can use Mediator pattern, if you use Galasoft Light toolkit then use messenger to send message from view to your viewmodel. Viewmodel register to that message and if recive one set your property in viewmodel and do some logic..
I am very new to WPF and am trying to set up an application that requires switching of views.
For example, a user is viewing a system that contains a number of components, when they click on a component, it should switch to a view that is associated to that component, replacing the previous system view. It's my understanding a Controller should be used here but the implementation eludes me.
I have found a few examples, but the projects are a bit too large for me to actually follow what is going on specifically with the view switching. What would really help me here is some example code from the Unity setup in the App file that allows multiple views, the Code in the controller that switches the view, and the code associated with a button that makes the controller switch the view.
Thanks
If you are just beginning with WPF and diving directly into using IoC/MVVM, then you may want to consider taking a step back and starting with the WPF fundamentals, i.e., layouts, routed events, commanding, binding, dependency properties, INotifyPropertyChanged, etc...
To get you started: tutorials on wpf and mvvm.
For most of us mere mortals, WPF has a steep learning curve. Yet, once you make it over that first hump, the 'aha moments' start kicking in on a regular basis.
I'm using Mvvm-Light, but I believe Unity will be similar.
You should have a ViewModelLocator where you register ViewModels.
You should have somewhere styles or datatemplates that tell the framework what view to show depending on the view model encountered.
You should have some property you bind to, that is a base view model.
From there, all you'll have to do is change that property to a different view model, and your view will update accordingly.
As Metro said, steep learning curve, but once you get used to it, it starts to make sense :)
I have seen a few examples where the viewModel (in Silverlight apps) is in the UserControl.Resources XAML section of a View. I read that for using Blend, this is a good place to have it (as it gives the ability to see sample data in Blend).
However, is this the best place to have the viewModel? I read that the "view has to push services to the viewModel". What does this mean and where else could or should the ViewModel be created?
Thanks.
JD.
There are lots of ways that the View and the ViewModel can be connected. The simplest approach is using the Resources like you mention or even easy just setting the DataContext of the View in the Xaml to an instance of the ViewModel.
From there things get more complex and really it depends on the framework you use:
Silverlight.FX - Uses a View base class with a Model property.
MVVM Light - Uses a ViewModelLocator.
Prism - Controllers
Caliburn - Presenters
So the approach you take will depend on what style you like. There are many ways to do this and right now there are a lot of MVVM frameworks showing up.
Well this question relates to MVVM pattern and i could good and fast answers on this forum so I thought to ask and clear the confusions i had about the pattern.
I am quite new to MVVM approach. I appreciate the pattern and understand the principals behind it. Maybe I have not worked that much with the pattern that’s why there are a few confusions.
If there is a scenario in which I want to load few parts of my WPF page dynamically with XAML and still want to be compliant with MVVM approach.
The confusion is:
Where the logic of loading a view dynamically with XAML reside.
Whether I should have a single ViewModel for my WPF page or each seperate part have its own viewmodel with interactions with other viewmodel classes.
What if I had to build control tree displayed on the GUI using C# code in the codebehind itself.
For the controls created using code should I do the commandbindings in the codebehind of the view itself.
Where the logic for loading goes is something not really addressed by the pattern itself. There's an interesting blog post about this by Ward Bell. There's any number of ways to skin this cat, and they're all compatible with MVVM. Not really the answer you're looking for, I know, but it's honest :). Check out Ward's blog post... you'll get a much more in depth discussion of this topic.
As for whether or not to have a single VM for the page, or one for each control, that just depends. Generally, I have one for the page. If there's some portion that reusable elsewhere, I break it out into a user control with it's own VM, which means we have a VM within a VM. I don't agree with rockeye on this one. There isn't a one-to-one relationship between V-VM-M. You're Models are designed according to business needs, with NO regard to presentation at all. You're ViewModels are designed according to your presentation needs, and may encapsulate more than one Model. In fact, it's very common for them to encapsulate many models.
Like rockeye, I don't understand your last question.
I am also quite new to mvvm, but i will try to answer :
Where the logic of loading a view dynamically with XAML reside
If you mean "how can i show the view associated with my business object?", IMHO, you don't have to care about this. Usually, your VMs have corresponding views. With dataTemplate, you use only VM in the code but Views are displayed automatically.
2 Whether i should have a single ViewModel for my WPF page or each seperate part have its own viewmodel with interactions with other viewmodel classes
It seems you have a top-bottom approach. I see the mvvm more as bottom-up : models (business objects) -> ViewModels -> Views. Every model should have its own ViewModel and view. So you can't have a whole WPF page in a viewModel unless you model represents a page.
3 What if i had to build control tree displayed on the GUI using C# code in the codebehind itself. For the controls created using code should i do the commandbindings in the codebehind of the view itself.
Don't understand. I think you may take a look at dataTemplate, it might be helpfull.