I’m writing a MVVM book – What would you like to see in it?
March 14th, 2010
I have started a quest that so many developers do; I am attempting to write a short book on the MVVM development pattern. When I say short, I mean short. Probably between 50 – 70 pages, most of it being code and examples. This is my first attempt at a book and I’m not quite sure what developers really want to know about MVVM. So please, feel free to let me know what you would like to see in a book about MVVM.
Small list of what I’ve been struggling with :
- Communication between viewmodels.
- Opening other views from a viewmodel.
- Working with modal view and dialogs from a viewmodel.
- navigation between views.
- Catching events from the view in the viewmodel (like when a user tries to close a WPF Window by clicking on the upper right close button).
- Blendability.
A common scenario is when executing code in a different thread, to free up the UI thread (so it doens’t freeze in long operations). How to do this async execution with the MVVM pattern?
@Anon
Actually I wrote a blog post about this one a while back. It is not specific to the MVVM pattern, but you would just put the code in your ViewModel.
Here is the post:
http://elegantcode.com/2009/07/03/wpf-multithreading-using-the-backgroundworker-and-reporting-the-progress-to-the-ui/
Let me know if this helps you out.
Great idea, looking forward to it!
- In LOB applications it is not unusual to use DataSets/DataTables in combination with editable datagrids (edit multiple rows, then commit/rollback all changes). Should you use MVVM or just the VS-designer drag-drop DataGrid/DataBindingSource/TableAdapter?
- Master-detail relations.
- Undo/Redo stack.
Thank you in advance.
@Taco
Well, MVVM is specific to the WPF and Silverlight technologies. It almost sounds like you are talking about WinForms. If you are in WinForms you may want to look at the Presentation Model pattern my Martin Fowler. Either way, MVVM is just a pattern, and like most patterns, it was designed to help in the all mightly quest of attaining seperation of concern, and testability. There is no rule or law that says you must use a pattern. If you are comfortable with code-behind, and binding directly to a table adapter, then by all means go for it. If you are interested in any kind of pattern based development, try to find one that you like. Just remember, patterns are just there for guidance, feel free to modify them to fit your needs.
@Brian Lagunas
I do realize MVVM is normally used in WPF/Silverlight. You asked what we would like to see in your book and I can imagine that it is quite useful for developers (who are switching from WinForms to WPF and it’s related patterns) to get an explanation in what cases to use the MVVM pattern and why to use it.
Imagine a WinForms application with twenty not extremely complex forms and a customer who wants them to be converted to WPF because of the dull grey controls don’t fit in the new ‘bling-bling’ company policy. Should the rusty developer who normally lives in ‘VS-designer mode’ switch to using the MVVM pattern and spend more time typing code? It would be nice if this developer can make the right decision after reading your book…
… and no, that developer is not me, it is someone I know
@Taco
I am sorry I misunderstood the point you were trying to make. I now understand what you are saying. Thank you for clearing things up for me.
For dialogs, use dependency injection in the same way that you would with service layer implementations. If you need help with this, contact me through my blog and I’ll send you some sample code.
What I’d like to see is a ThreadSafeObservableCollectionViewModel with SelectedItem and SelectedItems properties.
I am quite interested to know way of writing database application (mostly with SQL Server) in WPF using MVVM. So, including some sample (at least CRUD operations) on this topic would be great!
Most articles I have seen on MVVM focus on V-VM, and don’t go at all into the Model, some thoughts on that would be nice.
Also, I would really welcome some guidance on instantiation and dependencies organization: should the View come first? the ViewModel? Instantiate in code or bind in xaml? Where do containers fit with MVVM?