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
Related
I had been developping using WinForms for about a year now and I recently started discovering WPF. I have been more and more interested in this concept and started looking into the WPF's Framework MVVM.
MVVM
We can say that Windows, Pages, UserControls in WPF are Views
But what is the difference between Models and ViewModels?
I've looked at a lot of documentation on MSDN and some videos on YouTube trying to explain this.
If I understand correctly, the Models are basically the structure of your object (for example, Customers) and the ViewModels is what can work WITH the Customers object. Therefore I would bind my Window's DataContext to my ViewModel?
Did you read the MVVM article from MSDN mag? I'm guessing yes, since you're mentioning customers... msdn.microsoft.com/en-us/magazine/dd419663.aspx
If you've been coding OOP in winforms, then you've got classes to represent your data. That's nearly a 1:1 for what a model is. As a super-simplified way of looking at a viewmodel, think of it as the code that previously went into your code-behind for the controls of the page. It tells the view how to draw itself.. buttons to show/enable and the like.
So, in summary,
model::data as viewmodel::form_controls
I creating my first WPF application, and the goal of this is to basically be a data entry application for the database for CRUD operations (for example, creating a new customer in a new window, editing a customer, displaying a list of customers, etc). A database has been created, and I have thus created a Models folder to contain the .edmx file, dbcontext stuff, and partial classes generated from ADO Entity Data Model tool.
EDIT:
My question is, now, how do I go on with MVVM with my ViewModel and Models working together. All the tutorials I have seen show starting from scratch, and not using existing classes. For example, all tutorials would show creating a brand new Customer class, vs just going off the partial Customer class that was created for me.
I don't want to start over, so how do I follow these tutorials alongside the classes that were created for me through Entity Framework from my database?
In my opinion there is nothing wrong in Database-first approach, even it's quite good, because you would have general view at project (data side).
I would recommend you to start MVVM approach using Caliburn.Micro framework, it's easy, powerful and really nice.
Caliburn.Micro - getting started - part 1 - you can find there all 5 parts.
Caliburn.Micro - framework
MVVM does not specify where you start from, or how you deal with databases.
MVVM specifies you must get rid of the horrible code-behind hacks abundant in some useless dinosaur UI frameworks such as winforms and use DataBinding instead.
Therefore, just go ahead with your existing infrastructure, and make sure you don't manipulate or create UI elements in procedural code.
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
[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/
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