Following on from this initial investigations on Silverlight architectures, I have some new requirements to consider.
We expect our Silverlight client UI to be graphically heavy, with a GIS interface, multiple charts, gauges and datagrids arranged in a Widget style fashion. New widgets will be dynamically generated by the user.
Suppose a user wanted to dynamically create a chart widget from an existing datagrid widget pre-populated with data. It appears to me that if we were using a MVVM pattern with the view model on the server, this would result in an unnecessary call back home when the required data is already located in the client.
Now obviously the server needs to know about this new chart widget on the client, but how do I create the widget in the client first (with the existing client side data) and then notify the server about the new changes?
In our intranet, the network link between the client and the server is not particularly good so performance is critical.
It seems from my initial research that the common Silverlight architecture patterns call for as much of the business logic to be pushed back to the server. I understand the reasoning for this, but fear that it will really hurt the usability of our application.
Are there particular design patterns that address this issue? Is this 'client-binding' supported within MVVM, Prism or other common Silverlight architectures?
Is there a more formal name for what I am attempting to describe?
I am quite new to both Silverlight and design patterns such as MVVM, so please correct me if any of my assumptions are wrong.
The MVVM pattern is for separation of concerns. It does not define how or where you get your data.
The model, is data. It can be data you get from any arbitrary source. In silverlight, the most common way to get data is via a webservice (SOAP/REST). But your model can be any data from anywhere.
The view model is just another class that probably implements the INotifyPropertyChanged interface (So you bindings can automatically be updated). This class is an abstraction for your view's data. Let's pretend it has a string property called "FirstName".
The view is your UI (A user control in SL). You setup your bindings here to your ViewModel. IE, .
The view and view model are put together when you set your views DataContext. myView.DataContext = new MyViewModel(); There are many ways to set the DataContext depending how you want to set things up.
Prism is just a framework to help write decoupled applications in WPF/SL. It does not enforce the usage of any UI pattern (ie, MVP/MVC/MVVM). What it does come with is a bunch of classes can be used to assist with MVVM development, such as a mediator (EventAgggregator) and a dependency injection container (Unity).
So enough digressing...What I would suggest, is you have a web service where you can get all your data. You SL app would get that data (most likey the web services will be called in the view model). That data now exists on the client side and you can setup your VM to bind to this data in your view.
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 am using a WCF service reference in a WPF project, and my entity framework data model resides in WCF project.
And I am using MVVM Light framework. I am doing the following things:
I use LINQ in the service to get data and then fetch it from WPF, obersvablecollections usually.
Everything works in view part like populating datagrid, views as required.
But I have following doubts:
Is this correct way of transferring data between wcf and wpf.
I haven't used the Model for anything yet, I have doubt about when to use it?
I also wanted to save data from datagrid. I was able to pass on the observablecollection of updated data of datagrid to the service's function. But how do i update the entity from this collection? by looping? doesnt sound right. Once I update the entity from this collection I will be able to use saveChanges to update into database.
When I need to show hierarchal data in a treeview, where to make that data hierarichal, from stored procedure xml? use a view to create a grouping criteria column? create this column in service? create this column/property in presentation?
1 - There is no correct way, it depends on your requirements and goals.
2 - With MVVM, the model should sit between WPF and the database. That means all calls to the database should go through the model, and all writes to the database should also go through the model. The WPF GUI should only bind to the model. This usually means that your WPF portion consists mostly of XAML code. All code that accesses the database should be in the model.
There are good reasons for separating this.
You can write unit tests that on the model.
The view model is independent from the look of the GUI. This means that you can easily change the GUI by dropping in different components and just binding to the model.
A quick google search can probably yield more reasons.
3 - I would try to send over only the entities that have changed. This can be done by passing the collection to your view model, and have your view model figure out what has changed.
4 - I don't quite understand what you want to do. Usually, to make a TreeView, you should create HierarchicalDataTemplate for each of your view models. The TreeView control will take care of the rest. You should really do some tutorials on this one, because it's kinda hard to wrap your head around.
I'm new to MVVM and need a bit of help.
My application consists of a number of different windows which display controls allowing the user to edit the data in the Business layer.
At the moment, each time the user opens a new instance of one of these windows, a ViewModel structure - classes and collections mirroring the Business layer - is created from scratch and databound to the View on the window, and is also configured to access the appropriate parts of the Business layer.
This is quite sluggush at the moment, and I have a suspicion it is because the application has to wait until all the new ViewModels are created and configured every time a window is opened. I also notice the RAM gets munched up quite quickly too.
Would it be better to have a single ViewModel structure which is created when the application starts, and then all windows and controls refer to this single instance? What is the convention for MVVM?
One ViewModel per view is pretty standard. You don't want to share instances of ViewModels, since they are (usually) stateful.
I would look deeper into the sluggishness before concluding it's the creation of the ViewModel that's causing it. Profile the application with a tool, set some stopwatches, or debug the app and see what the bottleneck is.
do you need to recreate your viewmodels every time you access your views?
if not it seems you use view first approach, maybe you should then use a viewmodel locator?
you can also take a look at viewmodel first approach, maybe this fits more in your application.
I am kind of new to the whole MVVM pattern, and am trying to wrap my head around it. What I am currently trying to figure out is: in a well structured solution where do the ViewModels live?
Currently my design looks something like this (sort of):
Application (The view)
DomainSpecificCode (ClassLibrary)
Gateways (ClassLibrary)
If I were to add on another type of view (for instance ASP.NET or Silverlight), where would be the best place for the ViewModels to exist?
ViewModels should go in the Application layer because they tend to be technology-specific.
For example you may want to databind a View attribute to a particular color based on the state of the ViewModel. However, Color is implemented by different types on Windows Forms, ASP.NET and WPF, so you wouldn't be able to reuse the ViewModel accross different technologies.
If you add new Applications, you must also provide new ViewModels.
Recently, I built a MVVM Desktop application that had 2 flavors:
WPF Document Base GUI
Console application
Both exe were using the same view models, one was WPF and the other one was not.
I was able to split my solution into the following projects (libraries/exe):
non-project related re-usable code (called Common)
project models + persistence
project view models
WPF application + views
Console application
It was amazingly easy to build the console application version just by using the View Models. The console application code had less than 200 lines of code, and was basically loading the ProjectViewModel and doing operations on it.
This article describes a concrete Architecture for WPF MVVM Applications.
Layers:
Presentation Layer: Views
Application Layer: ViewModels
Domain Layer: Domain specific code
I have successfully created a asp mvc app which basically has interface, service and dataacces - AKA the repository pattern..
What would be the best way to call my service (my repository pattern) from an MVVM structured WPF app..
From what i see.. in the MODEL in wpf i presume i call my service (repository pattern) from the model and then return data to my viewmodel for displaying on the view??
Should this model be thin i.e. has little code and just call the service.. and return data to the viewmodel for processing or should the MODEL call the repository service and do the processing in the model before retruning to the viewmodel??
I am a little confused how i can use my WORKING repository pattern in the realm of a new WPF MMVM app i am designing...
Any ideas?
Thanks
I think you are complicating matters by focusing on the fact that your data access uses a repository pattern. It's irrelevant. You could be using Joe's Box' O' Data pattern and your underlying question would be the same. Let's forget you are using that pattern and focus on what you are doing: getting data from a data source.
When you get data from a data source, this is generally considered to be your Model. It's data, but it lacks certain behavioral things that make it appropriate for showing on the screen (lack of INotifyPropertyChanged implementation, for example). What people generally do with this is adapt their business objects into something that can be more readily used by a view (a view model).
You will use this technique regardless of the pattern in use for getting your data.