[Disclaimer: I'm ASP.NET MVC Developer]
Hi,
I'm looking for some best practices with implementing MVVM pattern with WCF RIA in Silverlight 4.
I'm not looking to use MEF of IoC for locating my ViewModels. What I would like to know is how to apply MVVM pattern with Silverlight 4 and WCF RIA.
I don't want to use other stuff like Prism or MVVM Light toolkit. I found many examples on Internet showing how it is wonderful to drag and drop a datasource on the view and the job is done (it reminds me about my first VB6 developments).
I tried to implement MVVM with WCF RIA and it's not strightforward at all. If I understand, the MVVM should contain all the logic in order to unit test it in isolation but when it comes to combine it with WCF RIA it's another story. I have the following questions.
Can I use a generated metadata as model ? It would be easier to use it that if I write all from the scratch.
As I saw the only way I could get data is through DomainContext or through direct binding in the view (local ressource). I don't want the direct binding in the view, not testable at all. On the other hand I can't use DomainContext, it doesn't expose any single entity !!! All I have is the EntitySet that I can bind to datagrid. How do I bind a single Entity to the DataForm from the ViewModel ?
How do I udpate the model to the database ?
How do I navigate from one Entity to a collection of it's items. For example if I have a Company Entity I would like to show a DataForm to update an entity informations and a datagrid to show companies adresses. When saving a form, I would like to save an information to Company and an information to adress about which adress was selected as active.
Please help me understand how to do it well. Or maybe I should drop the WCF RIA and to do it with WCF from scratch ?
What do you think ?
You might be interested in this session. It explains how to use the MVVM pattern with RIA WCF Services.
I found this post useful:
http://www.astaticstate.com/2010/04/silverlight-4-using-mvvm-patter-ria.html
Some random answers...
I don't think that MEF is particuarly well suited for Silverlight. It's primarily for desktop apps, and could be adapted for other uses where the plug-ins are in the local file system relative to the app.
MVVM requires that you understand roles. The "view" is your XAML and code-behind. The code-behind should handle events from the user control, but very little more than that.
The ViewModel holds the data that the user control will bind to. Generally, the ViewModel is bound to the View as its DataContext, so that everything in the form can databind to properties in the ViewModel. The ViewModel must implement INotifyPropertyChanged, and raise property changed events for every property that the form databinds to.
You'll probably want to create an ObservableCollection, using an EntitySet as your source. This will handle INotifyCollectionChanged for databinding purposes. If the entities in the EntitySet also handle INotifyPropertyChanged, then you're in good shape on databinding for collections.
You can create a property for an individual entity, and databind to that, assuming that change notification is also implemented (both for entity members, and for the entity property).
RIA Services will regenerate the DomainContext on each build, which helps a little in keeping it in sync. It's intended to be a service layer above an ORM, though, so your ORM or other data mapping will still have to be maintained by other means.
I haven't looked at the final release of RIA Services, but I wasn't hugely impressed with the beta version. I'd rather have good entity classes defined on the server, and share them with the Silverlight project. It's not easy to set up, though, and requires some non-trivial WCF that doesn't rely on service referernces. (RIA Services final release may have cleaned some of this up, but the native WCF service reference in Silverlight is pretty much evil, mainly because it doesn't automatically recreate generated classes, and it hard-codes the URI for the server-side service.)
Metadata was another problem with RIA Services beta. It's easier to attach metadata attributes directly to your DataContract class and the individual DataMember properties, if you control the entity source. Again, that may mean not using RIA Services. Writing a separate metadata class, as was required for the RIA beta, wasn't a good solution.
I ended up not using RIA Services for Silverlight 3, and didn't regret it. Here's an excellent article on WCF and Silverlight. Although it says Silverlight 2, it's still on-target for any Silverlight release.
I do recommend MVVM Light. Source is available on Codeplex, if that's an issue. It provides messaging and commanding support, as well as a ViewModelLocator; while the latter takes a bit of work to understand, it's really a good extension to the basic MVVM model.
Hope this helps.....
Just thought I would let you know about a project I am working on - just got our first release done. Provides a great simple way to approach MVVM for Silverlight + RIA Services specifically. Simplifies a lot of the MVVM stuff, and provides some more controller-like functions with the Notifications class. http://slmvvms.codeplex.com/
Related
I have a WPF GUI application based on MVVM design and data binding. Now, I want to reuse the core code (i.e. the data model) in a Windows service, or a console UI app, or a WinForms app.
Is such a design reasonable? If yes, what are the pitfalls?
Or should I make a standalone data model instead, and interface WPF via wrappers?
UPDATE:
Sorry, I should have been more precise. Let me clarify: I don't doubt the very modularity thing =) My concern boils down to having my current DataModel implement INotifyPropertyChanged, use DispatcherTimers, etc. -- all that non-GUI but still WPF stuff. The model's business logic is based on it.
Is this (non-GUI WPF) design acceptable for reuse in the aforementioned cases, or should I abstract further, until no references to WPF would be required at all?
Yes, this is perfectly acceptable and most of the time it is desired!
When you build an MVVM app, it should be in at least 3 formal layers:
Presentation WPF, UI, xaml, behaviors. All that stuff. Not reusable
Application The view models and structure that supports your application rules. All that stuff. Not intended for reuse
Foundation Database access, business objects. Domain specific algorithms. Ideally this bit should be reusable anywhere
The foundation layer is the clever bit. This is where the meat in your application sandwich is. It makes perfect sense for this to be totally agnostic of UI technology. WPF, winforms, ASP. It shouldn't even need a UI.
Edit for question update:
Removing all references to WPF is hard because sometimes you need a CollectionViewSource on your view models for grouping/filtering of results. That is a WPF class.
It is very tempting to view your seperation-of-concerns as 'just dont reference wpf' and that helps but it can make life difficult. Instead, try to be disciplined with the type of behaviors you are putting in. If you find yourself writing 'clever' (domain) code on a view model, shift it to the foundation layer as a business object method or extension. Similarly, if you find yourself implementing IValueConverter often, perhaps you should make better use of view models.
One thing is for sure, your foundation layer should never, ever, ever reference WPF.
Such a design is very reasonable! You can create a portable C# library for all .NET technologies including WPF, WinRT, ASP MVC, etc which can contain your models. Obviously you'll need to wrap these portable models into a viewmodel anyway, but IPropertyChanged is implemented in all XAML flavors.
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
In many ways I think of using the MVC pattern in WinForms, but I'd like to know if it's possible to bind controls with objects using the ObservableCollection type? If it's purely for WPF, what other alternatives are out there?
To put it into perspective, we're building a system which has business logic that I'd like to control the UI with, instead of making customizations for each requirement or workflow on the UI itself. We have around a few hundred potential forms which I'd like to start designing with the pattern in mind.
We're also building web interfaces for most of the processes, but in reality they're just watered-down versions of the Forms. If I can use the same framework which I can just bind to on the web form that would be awesome.
Thanks
What ObservableCollection does is that it implements INotifyPropertyChange and each control in WPF has the possibility to listen for it's bound data to raise the event from INotifyPropertyChange. You can read more here about why you can't use ObservableCollection they way you want to in WinForms.
Another way is to use the Model-View-Presenter pattern:
This pattern can also be used in ASP.NET.
There's an MSDN Magazine Article on: "Better Web Forms with the MVP Pattern" that I think you should look into. And here is an introduction to how you use MVP-pattern in asp.net.
I have a Silverlight class library which is a model in my MVVM app. I am using MVVM Light. How easy is it reuse that model in a WPF app and use the MVVM Light framework. The framework has different dlls for WPF and Silverlight so I guess there is incompatability of sorts. I was wondering if anyone could talk me through the options. Cheers, Chris.
The suggested option is to use the Project Linker, this tool synchronizes code over multiple projects, allowing you to maintain a Silverlight and WPF dll with one codebase.
I hope you mean model means data in WPF and Silverlight. If that is the case, you can expose the data using a Service. It can be any service like web service, WCF service or WCF RIA service. Since a service can be multi tenented you can have a Silverlight as well as WPF client accessing the same service.
If you are trying to share the ViewModels between Silverlight and WPF using MVVM light, I would suggest you have a look at the MIX 2011 video of the presentation by the creator of MVVMLight library Laurent Bugnion. This is called Deep Dive MVVM and is a very good session. In short you can share ViewModels between WPF and Silverlight by adding the file from one project to another as a "LINK".
Hope this helps
I develop in WPF with EF (EDM designer entities).
I now want to move to Silverlight+RIA, and I am looking for a turorial, video or whatever that will guide me how-to to use Silverlight RIA with MVVM using EF as the model.
I have extensive knowledge of: .NET 4, WPF, XAML, DPs, DataTempaltes, EF 4.
I am familiar with Silverlight, WCF RIA and MVVM.
There are two things about LOB+MVVM I am encountering difficulties:
I am looking for a way to template my work, so I don't have to copy-paste the content of my ViewModels, what I mean by that is having a generic ViewModelBase that will handle a certain type of Model(s):
ViewModelBase where TContext : DomainContext, TModel : Entity`
Another difficulty is the overall composition of the UI; say I have a branch of master detail that gets complicated more and more all in one screen. I want all the parts to be divided into tiny Views each for its point. The problem is, I don't know how to expose the data for the inner views, say the main view's DataContext is set with MainViewModel, and there is a property Contact in the MainViewModel; how would you set the Contact view inside the MainView, setting the inner view (the ContactView)'s DataContext to ContactViewModel AND setting the ContactViewModel's Contact to the current Contact from the MainViewModel, what is the right technique??
NOTE: I am self-employeed, no teams and not other developers, so I don't see a reason splitting everything into modules, I don't mind if the whole project will reside in one project split into folders etc.
I always find Mike Taulty's blogs useful for this sort of thing.
So try this followed by this.
And on the MVVM side of things I use the MVVM Light Toolkit, also try watching this very good video by Jason Dolinger