Let's assume I have dragable nodes in an WPF MVVM application. I need to load and save the position of a node as well as its logic. The simplest approach would be to save the position along with the logic in one xml file through a repository. However, that would mean I have view information in the model and view model.
Is there a best practice approach regarding this scenario, maybe one that I have not considered so far?
If your application cares about the positioning of the UI elements it displays to the user, then I 'd say that the data defining this positioning is a very legitimate part of your Models.
Don't confuse the ideal of decoupling the UI from your Models and ViewModels with real business requirements. For example, in an application like Visio you could say that the exact placement of objects in the page is a "view-only detail", and what matters is only the properties of the object and the connections between them. However, from the user's perspective, the placement of objects in the workspace very much matters. In other words, it is part of your data model.
Related
I'd like to create a Silverlight app using WCF Ria Services and the MVVM design pattern.
The main page of the app will consist of a "shell" and a large number (10s or 100s) of objects of different look (shape/size/properties) linked to each other (forming a sort of graph).
These items need to be mouse-draggable and their current position/state needs to be saved to the back-end database.
I feel that the best way to achieve this would be to have a small ViewModel and View for each item displayed, put all the important properties into the ViewModel and then somehow display all these Views in the main "shell".
However, I don't know how exactly this could be achieved. I considered using MVVM Light, but didn't find any example that would show something similar.
Can anybody point me to some examples or ideas about how this could be done?
"When all you have is a hammer, everything looks like a nail" :)
MVVM is not designed to manage graphic intensive situation like the one you describe. It is a glue for stitching together high-level concepts in a flexible manner. With MVVM you are adding overheads that will impact performance (e.g. binding uses reflection behind the scenes). The more objects involved, the greater the impact.
The best starting point I can suggest is to imagine what you need from a 3rd party control (e.g. a custom control/container) and, if one does not actually exist already, build it as if it were a third party custom control.
You will find in practice that custom controls are seldom based on MVVM, for performance reasons if not just because "they often don't need it". They may well expose MVVM compatible properties for the external interface, but not for the low-level internals.
MVVM is a relatively high-level technique. Do not feel you have to implement it on everything.
Following MVVM do the next:
Model - create model object which will be responsible for fetching and persistence coordinates of the shapes on the screen;
View Model - one view model which will initiate fetching and persistance model objects;
View - in your case, it's a place where you do most of your work. Create custom control based on ItemsControl with Canvas panel. Custom control should pass collection of the model objects in ItemsSource, allow to drag and drop containers and call the view model command when user drops container in some place
Have a look at the Telerik controls, specifically radTileView, this seems to have the functionality that your looking for. They also have a persistance framework that should allow you to save the position of the tiles back to you database.
I'm trying to get up to speed with using WPF and the Prism framework which is heavily associated with the MVVM pattern. I've ready many different descriptions, examples and discussions on MVVM and each one is slightly different and has left me a little confused.
My understand is as follows:
The MVVM pattern has 3 parts to it :-
Model - the classes that hold the application data/information.
View - The visual elements of the application.
ViewModel - The logic, state and other behaviour associated with the visual elements. It takes data from the model and exposes it (possibly with some data conversion/formatting) in such a way that the View can use it directly.
What I'm not sure about is:
Do these 3 parts cover every part of the application? Or can there be parts of the application that are outside these 3 parts?
Is it the ViewModel or some other part that is responsible for populating the Model?
Thanks in advance
Absolutely not. Unless they do. If your application is simple, then everything can be handled in the View, ViewModel or Model(s). If your application is complex, and best practices dictate you break out logic into their own types (communication logic, repository logic, etc), then there is no stopping you. MVVM is only concerned with view-centric logic within the View, application logic within the ViewModel, and the means of storing information for transmission between the two.
The ViewModel is solely tasked with interpreting user actions and readying the results of logic within Models so that the View may display this information to the user. In some cases, it makes sense that a Model itself hold some logic so that it may respond to user actions. However, it has been my experience that this mini-ViewModel-Model design is in reaction to design decisions by inexperienced developers. Once you get the real hang of MVVM, you usually don't have to (or want to) put any code in your Models apart from validation logic.
Think of Model, ViewModel and View as logical layers that handle Business, application flow and presentation respectively. For example, a ViewModel class may delegate complex or reusable UI interactions to a separate service that doesn't correspond to any particular view but still belongs to ViewModel layer.
Yes, ViewModel stands between UI and Model.
The question is stated in the subject: are the advantages of Model-View-ViewModel (MVVM) pattern worth the overhead?
In many cases, implementing the view model involves quite significant overhead of duplicating the Model properties and sometimes synchronization between Model and ViewModel data members. For example, currently in Silverlight 4 & WCF RIA, View Models are not generated (if the developer follows the MVVM pattern, it is up to him to create the view models, often duplicating the corresponding Model's properties at ViewModel, that do nothing significant but refer to Model as the storage).
Why not extending the Model class, providing additional properties to make it easy to be consumed by the View instead?
Why not extending the Model class, providing additional properties to make it easy to be consumed by the View instead?
Effectively that is what the PresentationModel is for. Which MVVM is strongly based on. The difference is that the ViewModel is the model for the view and not the model for the data. So you are concerned around more how the view behaves with the data.
If you have a simple UI that all it does is present the model then I would suggest expose the Model on a property of the ViewModel and bind to that. Make sure though the model does implement INotifyPropertyChanged etc.
The power of the ViewModel is when you have things to do in response to a user action. The ViewModel can then support Commands, calling out to services and validation and thus leaving the Model as a data container
Why not extending the Model class, providing additional properties to make it easy to be consumed by the View instead?
In the simple cases, this is all the ViewModel is doing - wrapping up the Model so that its extended in a way that's consumable by the View. If your Model can be bound directly, you're welcome to do so.
That being said, there is more to the ViewModel layer than just wrapping the model - this is also where the application specific logic - ie: the application's plumbing, will occur. Something has to make the requests from the Model classes correctly and compose together the logic.
If you are concerned about extra work, you can always create a ViewModelBase (INotifyPropertyChanged , Errors/Validation, generic stuff) to be inherited by your ViewModel, it will minimize things that you think may cost you time to replicate. And also, Silverlight/Wpf provides us with binding which greatly reduces our coding, besides the fact that XAML also does that by providing functionalities through markup. Besides that you can further the design by using screens, controllers, etc.
For me, I do not see any "overhead" with regards to using MVVM; if there were, it'd be worth it. It properly deals with the Separation of Concerns. It provides a good platform for development especially in teams where people may take care of different aspects of the application without affecting other team members codes (especially between developers and designers).
Hope this helps
Benefits of MVVM
Reduced complexity.
Isolation of Designing and Development.
Dependency injection.
Major advantage is when you have a Well MVVM structured Windows Phone application and want to develop same for Windows Metro Desktop, Only thing u want to concentarte on design as the same view model can be used as it is.
Hope it helps.
When I'm designing multiple views under the MVVM pattern, does each view get its own ViewModel or do they all share the same one? I understand that this is ultimately a flexible decision, but what is the best practice?
My gut tells me to have a ViewModel for each view (i.e. each separate UI window). All of the blog examples of MVVM show a single view but not much beyond that.
Yes, basically the idea is that your viewModel should only be used by one view. If you use a viewModel to populate an area (like in ASP.NET MVC) then that viewModel is "reused" each time that view is presented in difference places.
This article is a discussion by Josh Smith of the MVVM pattern. Then, Ward Bell discusses in this article what he thinks Josh left out, while maintaining that Josh's work is still very strong.
Ward does an excellent job of laying out the complexities of this pattern and showing the tension that exists. Here is his take on the tension:
In my experience there is a “dialog” between View and ViewModel design. The VM exists to serve a view even as it strives for independence from any particular concrete view. A VM is useless if there is no view that will work with it; clearly the VM developer must
heed the imprecations of the View developer.
On the other hand, in business applications the application’s imperatives – what the view must do to satisfy business requirements – are the province of the programmer and are > best articulated through the capabilities of the ViewModel.
Therein lies the necessary tension between View and ViewModel design. As a developer my allegiance is with the ViewModel (“the application should do something worthwhile”) but it would be silly to defend that allegiance at the expense of the View (“a good UX is essential to making an application easy to learn and to use”).
To me thats a subjective statement- text book, I would say definately a 1-1 pairing - and there is certainly nothing wrong w/ being proactive and setting the paradigm by having a 1-1. However, if you have multiple views each representing a slice of the same data you dont necessarily have to have 1 per- you could reuse the same one across multiple views until you had a deviation. The purpose of the view model being a bridge between the ui and the business layer...if the business functions are the same you are either going to have a common view model interface or base and cast down or you are going to be replicating the same logic multiple times. If the view is the only thing that changes I see no issue in reusing the same view model until there is deviation.
In wpf, you should be binding to values on the model so unless your view model has a reference to your concrete view that shouldnt be an issue. Even it does, you could abstract out to a view contract (interface) and change the property to be that type instead.
Yup, each view should have its on ViewModel.
I don't know WPF inside out, but generally the ViewModel mediates between a UI component and a business logic component. In other words: It's specific to a view/model pair - this is the only reason for this component to exist...
HTH.
WPF's view model oriented way of doing things makes it very tempting to just use business objects in the UI. Have you seen any issues with this? Why or why wouldn't you do this?
The guidance from Microsoft's product teams (e.g., that's what the Blend team is using) is the Model-View-ViewModel architecture, a variant of the popular MVC pattern. A good starting point is http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx. There are also good articles by Dr. WPF on this topic.
Essentially, they advocate to create a ViewModel layer which uses binding-friendly business objects, such as ObservableCollection and the like.
Also, if you might eventually move to Silverlight 2, you might want to keep the business objects out of the UI layer so you can swap out UI technology (until WPF and Silverlight become source-code compatible).
I guess I see it in a different light. I try to keep as much out of the UI as possible so I can use whichever UI presentation I need (ie. web, WPF, WinForms). The more business logic in the presentation layer, the more you may have to rewrite later if you migrate towards a different UI.
It's not a problem having business objects in the UI, as long as all you're doing is viewing them. In other words, if you want to change the properties of one, or delete one, or create a new one, you should be sending a message to the controller, presenter, or whatever to do that; and the results should then be updated in the view.
What you shouldn't do is use the ToString method of your objects (or any other methods or properties on your objects) to affect how they'll appear in the view. You should use DataTemplates to represent the view of your objects. If you need a more complex representation, you can use an IValueConverter to change the object into its visual representation.
Not being a WPF guru, I can't be sure, but the usual reason for separating your M, V and C is so you can test the controller independent of the view, and the other way around.
Nothing stopping you, of course, but it should be a lot more testable (ie, unit tests) if it's separate. The MVP pattern, which is usually the one that MS promotes, is more geared around the presenter (ie, your WPF form) having more control, and thats fine too....
Depending on your application architecture or the on the way you are planning to reuse your components and objects, you can choose a certain degree of independence from the user interface (in this case WPF).
Here is a sample of my experience:
I've worked with WPF just a little, on
a relatively small project, where the
business layer was already defined,
and we just needed to create a user
interface. Of course, the interface
had defined it's own rules and objects
that it was working with, and because
the application was defined just for
UX we have chosen to create our own
specific objects, mostly by extending
DependencyObject (mainly for Data
Binding purposes).
Some people may argue that it's not ok
to use dependency objects because they
not are serializable (actually they
are - to XAML), they bring a
dependency to WPF (the
System.Windows namespace), and some
other arguments. Also,
DependencyObjects support other
options, like attached properties
and dependency properties. Others
might like to use for example
INotifyPropertyChanged if it
makes sense, and others might say that
all of these patterns don't belong in
other layer than UI.
(If you want to learn more there are
some good WPF data binding
articles in the MSDN library,
including best practices for
perfomance and for user interface)
It's kind of bad that Microsoft has chosen to add some of the goodies to the System.Windows namespace, instead of, for example, to the System.ComponentModel where in my opinion they might have been more useful (by providing all of these important patterns not only to WPF but to the .NET Framework).
Of course this is just the beginning and many of us know that the thing will be evolving to the right direction in the end. (With the risk of going off-topic: Take silverlight 2.0 framework for example. It was a rushed release, with some of the objects in the WPF model missing and some not in their natural place.)
In the end, everything depends on you, your programming style, your architectural decisions and your knowledge of the technology.
If it seems more natural to do it in a way, than by the book, think why you should and why should you not before taking any decision!