Have some experience with WPF and databinding, but completely new to PRISM and MVVM.
I'm working on Prism application where I have a shell and multiple modules.
In my previous WPF application I had a single window datacontext (with all objects I need) which I could then simply databind from any usercontrol inside my window.
In the context of the Prism, what is the proper way to have a single datacontext, let's we call it ShellViewModel and then for all modules to bind to its' objects and properties? So if there is a change in one property in ShellViewModel which is caused by one module, another module can detected that by databinding and then maybe trigger a style?
Probably there is a simple way to do this but I'm new to PRISM and MVVM and completely confused how we can do properly bindings especially when there are multiple modules involved?
Also any source code and examples would be great.
If you have a single source of data, make it available to all your view models as a service.
Register it as a singleton, so that all view models get the same instance. If you need the service to push updates to the view models, make it implement INotifyPropertyChanged and let the view models observe that (done best through a PropertyObserver).
Remember that the view model is the data context of the view, and that it should only communicate data and events between the view and the data source a.k.a. model, but should not own data itself.
Related
I thought we should have no reference from View to ViewModel in MVVM Pattern. but just saw an MVVM Sample from code.msdn.microsoft in which ViewModel implements new Window and shows it;
By using MVVM-Light toolkit you use Messenger to Call or Open new Window and Still keep Separate the View and ViewModel form each other. Is it right to reference the View in ViewModel? Or it is wrong;
Do you suggest to call Views Directly from ViewModel for large(or medium) projects?
http://code.msdn.microsoft.com/windowsdesktop/Easy-MVVM-Examples-fb8c409f
YAGNI.
Level of effort and complexity.
MVVM is just a pattern. A pattern you don't have to follow. Any little tool I write for my own use just uses a model, a viewmodel, and a view. The viewmodel exposes all properties I need for the view by INotifyPropertyChanged. The data is moved back and forth from viewmodel to model manually using ViewModel.FromModel(model) syntax. I don't bind to my models. I only use the model when saving/loading data; I don't hang onto it. My views are generated using dataTemplates and dataTemplateSelectors. If I have a property that should change the layout I expose that on the viewmodel and use a selector. Otherwise, I have a datatemplate for every viewmodel object. And it just works.
I call this a form of MVVM, even though it doesn't any toolkit or the exact MVVM pattern that Microsoft describes.
I would personally implement a service to drive commands from the viewmodel to generate new views and hookup the viewmodel. But that's because I have MVC experience, and I think generating views is easier to do using the MVC pattern, whereas desktop views work better using the MVVM pattern.
All my views are composed with contentControls. Setting the content is setting the viewmodel.
So I use a hybrid.
If your software isn't so complex to need the complete Microsoft endorsed MVVM pattern, why create the overhead code IMO. YAGNI.
IMO, having a strong reference from the ViewModel to the View has 2 problems:
It breaks the testability of your ViewModel code. This means you won't be able to Unit Test your code so easily, and if you do you'll have to account for Dispatcher issues and the like.
It makes your ViewModels dependent on WPF assemblies and types. This means you won't be able to literally copy and paste your ViewModels into other applications or platforms such as Xamarin.Android or the like
If none of these are important to you, I don't see any reason why you wouldn't. Not doing so creates additional overhead in your code, by having to implement WindowManagers and whatnot.
I am developing a little utility view that will be embedded in several of our apps. It will sit in a common library.
Should I expose this as a ViewModel along with a default View implementation, or would it be better as a UserControl with a fixed GUI?
It is pretty self contained and I doubt it will need to be reskinned, but doing it as a UserControl seems a bit overkill with having to set up a load of dependency properties.
A simple ViewModel seems more attractive to me but wondered if this was the normal way of sharing stuff?
EDIT:
It would also be nice if I could embed this in WinForms apps too. Is this possible with View/ViewModel?
Well, in the end I went with View/ViewModel. This keeps the separation nicely and is easily pluggable into existing MVVM projects.
It also works fine in WinForms, given that a View is just a UserControl with its DataContext set to some arbitrary object (the ViewModel).
The only slight issue I had was the fact that Application.Current is not set in a forms environment, so I had to store the GUI dispatcher reference so I could marshal gui updates to the proper thread in my ViewModel.
I have a MVVM/WPF based application that can have multiple workspaces (basically containing a TreeView) open at the same time that display and operate on the same data tree. I need to be able to expand and collapse and select the items in each workspace independently and I want to be able to drag and drop items between the two workspaces (e.g. for moving or duplicating items). I also need data virtualization in that the data is only loaded (in both views) when a tree item is expanded for the first time. There is also one workspace-wide details view that shows the details of the selected item of the workspace that currently has the focus. Workspace specific expansion and selection of items must also work programatically.
Could you layout a ruff design for a MVVM based application that embraces theses features? Should I create a separate ViewModel tree for each workspace and implement a Model-ViewModel mapper? Or should I have just one ViewModel tree with two Views? How does the details view know what is currently selected and what workspace has the focus? ...
So to rephrase my question: The Model instances displayed in each View are actually the same instances. But should the ViewModels be the same too? Or better: Could I possibly get away with that?
Also: Is there an open source application I could study that has most of these features? Could Prism or any other MVVM based framework do most of that work for me?
There is a direct correlation between View and ViewModel. The View shows a visual representation of the Model, hosted and "formatted" by the ViewModel.
Since you will have different Model (data) on each View, you need to have several instances of your ViewModel hosting each set of different data.
Now the question is: do your ViewModels share some entities or objects between them ?
If yes, could they change during your application lifetime, and do you want to see these changes in realtime in your TreeViews ?
You then have two options:
Directly bind the model to the View (if the model implements INotifyPropertyChanged) by exposing it through your ViewModel: then all your views will be automatically updated when a model property changes.
Create a component which supervises Model modifications and notify ViewModel exposing them.
The second solution is more pure than the first one because Models should be POCO and shouldn't implement some plumbing oriented-interface. ViewModel should handle the plumbing.
However it's more complicated to design, and 90% of the time, you will end-up saying "come on, just one little interface doesn't hurt" :)
For your details view. You can communicate between your TreeViewModel and your DetailViewModel using a mediator (Messenger in the MVVM Light Toolkit), which is basically a low-coupled event-oriented component. Or use a supervisor which is injected in all your ViewModel and notify them using events.
Speaking of MVVM framework, and for common architecture like the one you are describing, I would recommend the MVVM Light Toolkit.
Maybe I am missing something, but is it not possible to have 2 instances of the same View / ViewModel loaded with different data?
I'm working on a Windows Phone 7 app with a designer. I've done C# development with XNA so I know C# but was not familiar with the Model/View/ViewModel architecture.
Our first crack at it had multiple ViewModels active for any given view. Each ViewModel was an in-between layer for each object in our model.
For example: We had a "Friends" page that has a ListBox that displays the list of Friends. So we made a FriendsListViewModel that would handle getting an ObservableCollection<Friend> from the Model that the XAML would bind to. There were other functions available in the page (navigating to other pages, activating semi-related features, etc.) so that was contained in the FriendsPageViewModel.
This was starting to look crazy to me, so I made the relationship between View and ViewModel 1:1.
With all that described, I've got a question with two components:
With MVVM, what is the common relationship between Views and ViewModels? (focusing on Windows Phone 7 development here in case it's any different from ASP.NET, WPF, or Silverlight)
And as a possible addon to that question: Say the 1:1 relationship is the generally correct or accepted one: If you're dealing with something like a Pivot control or Panorama control, would you typically give each PivotItem or PanoramaItem its own ViewModel?
In MVVM, you typically have one ViewModel for each View (exceptions exist). The View typically 'binds' to the ViewModel which is the glue between the view and the data model. Your view can contain multiple controls and each control will bind to a particular property (i.e. data source) on your ViewModel. The ViewModel will then notify the View once one of these properties is updated (via the INotifyPropertyChanged interface in C#).
When thinking about ViewModels, don't think of it as a single ViewModel per control. Think of the control binding to a single property of the shared ViewModel.
The ViewModel provides data from the model to the View. The View should only be used to display the data it gets from the ViewModel. Keep code in the View to a mimimum and only pertaining to rendering control elements. The ViewModel is responsible for querying data from whatever the data source may be and then providing public properties the View can hook into.
This MSDN link has a pretty detailed article on it, but you can get a good synopsis on wikipedia.
i am new to wpf and i am designing a client-server application using wpf for UI
i have one view - view model, datalist and communication model
my view and view model will form one user control
following are my doubts:
if i keep my datalist inside viewmodel, how other view model can access it
if i keep my datalist in application so that any view can access it , whether my view model will be able to update it through binding
it will be good design if my view model calls my communication model directly or should i keep a wraper class in between.
thanx
sarika
You should think about using a repository pattern to access your list of items. Your viewmodels should work against an abstraction of this repository (e.g. IPeopleRepository), and you should pass a concrete implementation of this repository into your viewmodel via injection (e.g. through constructor injection). Your concrete implementation can call your communication model to retrieve the list of items.
Typically, your repository will return a collection type which is not specific to WPF. You'll probably want to wrap this in an ObservableCollection on your viewmodel, so that the UI is notified of changes to the collection.
Whether each viewmodel retrieves a new reference to this collection, or if they all access the same collection, will depend on your use case, but as long as the collection is exposed as a property on your DataContext (typically your viewmodel), then you'll be able to bind to the collection to display and update it from the view.