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.
Related
While adding extra functionality to the main view I have in my application, I've realized that the amount of code will soon become a problem (currently around 600 lines of code in my viewmodel and I still have plenty to add).
I've been looking around for articles on how to split/design your view into smaller components, but I haven't found a satisfying solution. One person suggested using child viewmodels but that presented with other problems (dependency between the viewmodels).
I've thought of using user controls, but there is nothing on the View that I use on other Views so it kind of defeats the purpose of user controls.
What is a correct approach in this situation?
Thanks,
Adrian
If you want to split a view into component parts, then you need to do view composition. If you are building an MVVM app, then you should really be using an MVVM framework. Something like Caliburn.Micro makes view composition incredibly easy.
There doesn't necessarily have to be dependencies between the view models, they should only know about what they need in order to produce their view. This could be a subset of the business object that the parent view model contains. As the parent view model will have references to all of the child view models, it can pass the relevant parts of the business object to them at the point of their construction.
I would agree with using Caliburn Micro.
However, to play devil's advocate you could split out your ViewModel File into separate files (same class name) and use the partial keyword before the class keyword. Its generally tidier and one step-away (non-breaking precursor) from breaking-up into separate classes.
I also agree Caliburn.Micro is a good solution for splitting your application in smaller components.
In Caliburn.Micro the communication between viewmodels is based on the Event aggregator pattern.
This makes a loose coupling between viewmodels
Splitting up is not ideal.
It looks as if the Caliburn toolkit focuses on events, whereas my application largely relies on ICommand implementations.
To me, the first encounter with Caliburn.Micro has been unsatisfactory.
The setup appeared to be tailored to VS2010 - which sounded promissing to me - because I do have VS2010 pro. But I got lost in the setup's of Silverlight.
Compared to toolkits like Prism it lacks the ease of an start.
It just takes to much time to switch now.
I use my own MVVM paradigm, it is less abstract than the Caliburn, it integrates multilanguage support everywhere, and it just faces one acceptable problem of some sources getting too big because of the nature of the Binding/DataContext paradigm.
For this problem I accept that "partial class" is a solution - even though I know there is a more elegant solution available.
In the heat of my work, I cannot change to another toolkit.
So I gently wait for Microsoft to allow for more flexibility around that Binding/DataContext paradigm.
It may be the case that Caliburn shows more intelligence allocating a viewmodel to some item. Does it ? (I think it does.)
What might be another option is to define a custom (xaml useable) object that triggers a custom allocator which control is to be allocated to which viewmodel. How about that ?
I am building a rather large WP7 application and having a lot of fun with it. It is Pivot based and has quite a lot of pivot pages. I dynamically add and remove pivot pages based on what "mode" of the application the user has selected to keep the application look and feel as simple as possible. All is going quite well so far my app is fast responsive, not a memory or resource hog and performs background loading on demand when needed.
The Model layer contains all my business logic that represents what the application is all about. It is clean and separate from the the view-model and view layers.
The View-Model layer is an abstraction of the model to the extent that it needs to interact with the view and also contains the session-ness and workflow aspects of the application in general. It contains objects which represent the Model in a way the View needs to interact with. The view model persists the state of the application in isolated storage and supports tomb-stoning.
The View layer contains a lot of elements pivots, user controls, styles, resources etc in both xaml and the corresponding code behind. I do like Blend and the Xaml designer within visual studio 2010 however I find myself still coding/configuring the view objects within the code behind due to the nature in which they interact with each other. The code behind of the view objects is becoming quite large but still only reflects the state of the view and not the state of the application. I have made use of user controls quite a lot as this lets me build reusable components across many pivot pages however the user controls are not Blend friendly. What I am worried about is that my view might becoming more complex than it needs to be and losing the ability to coordinate the user interface design with tools like expression blend.
By customising the view this way and making use of reusable controls I have reduced my Xaml considerably and don't suffer from bloated Xaml files that other developers have mentioned but lost ability to co-ordinate with Blend. Is there are happy medium to be found? Should I be looking at designing custom controls?
[Edit]
Thanks for your reply. I think it boils down to either a lot of Xaml with a designer or break it down into user controls with more code behind. Since I moved into user controls my mindset has moved back to doing things by hand rather than with a designer (better the devil you know right!). My thoughts are should I make my user controls into skin-able custom controls or just keep going how I am and avoid using the designer. Its a bit of potato-potardo but I don't want to get into bad habits.
Custom Controls (or Templated Controls) are not directly related to your question as far as I can see. Custom controls are just controls that add new properties, events and methods to an existing control and are still capable of being 'templated' by a designer.
Creating UI in code does make it harder to design the application using Blend (and even the VS designer) because the only way to see the interface is by running the application.
A lot of the logic that creates the UI could possibly be replaced by using the Visual State Manager. Use states of the controls to design them for specific modes of the view. Only when you need extra/new states you will have to create a Custom Control.
As your question is a bit wide, feel free to add comments or extend your question so I can add more details or remove this answer when it is utter nonsense :)
I asked a question here about MVVM In MVVM there can be only one View for each one View Model?
Answer would be to use DataTemplateSelector to get multiple views. Now let's say I need to port to flex. Does Flex have the same paradigm as DataTemplateSelector?
Since Silverlight claims that it is close to Flex then I'd like to see proofs :)
Specifically, there is no "DataTemplateSelector". That is not surprising, though, because they are different stacks... (They ARE extremely similar to each other with regards to feature parity and developer paradigm) In Flex, there is the concept of skins, which are very similar to templates. There is also the concept of item renderers, which closely resemble data templates in repeated views (List, DataGroup, DropDownList, ComboBox, DataGrid, etc)
In the case of item renderers (most likely what you are talking about), the components have an optional itemRendererFunction property which is a function that decides which item renderer to use. It allows for extremely dynamic views to be slapped on top of Presentation Models (they are not called View Models in Flex... they use the original name of Presentation Model... not sure why Silverlight ever changed it to MVVM... I digress).
As for skins on all other (Spark-based) components, you can change the skins at runtime using .setStyle('skinClass', TheSkin)
In addition, you can use IoC containers to glue together Presentation Models with any view. This is actually very easy.
Along the same lines, I once built a very tiny view mapping engine that lets you register views against types and the data binding happens automatically. A lot like the RegionManager in Prism for Silverlight.
If you are interested in how Presentation Model fits within Flex, I have written two articles about the topic:
MVVM vs Presentation Model
Presentation Model for using in Multiple Screens
The second link will have a follow-up posted on Tuesday that describes how you use multiple views on top of the same Presentation Model.
So, yes. There are several solutions to achieve what you want to achieve. None of them are direct, because they are different stacks, but the functionality is certainly there.
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.
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!