Develop Reference

What framework for MVVM should I use in Universal Apps

I will develop new Universal Apps and I was wondering which MVVM framework will be better for me: Prism for Windows Runtime or maybe MVVM Light.
I have a little experience in WPF and in my opinion in this scenario Prism offer more. I'm developing also other Universal Apps and I'm using there MVVM light, but this project is simple and I use only binding, commands and ViewModelLocator.
My new project will be more advanced and I don't know what is the better way and what kind of benefits I can obtain.
I'm interested in this this Prism version: enter link description here

I develop in WPF & learnt MVVM by writing my own simple framework. It really helped me grasp a solid understanding of the fundamentals required. Really to get started you only only need to write a base class implementing INotifyPropertyChanged, an implementation of ICommand and decide whether to use View or ViewModel first principles.
I wrote a blog with tutorials which cover these issues:
WPF Retraining at 30

I would prefer caliburn micro, its a very good framework, i also wrote 2 blog posts about it a few months ago if you want to have a look:
Part 1 - MVVM Basics using Caliburn Micro
Part 2 - Navigation
I am sure if you search you will find a lot of tutorials on this framework... and I really like it.

Is the MVVM of LayoutAwarePage enough?

Currently I am using MVVM Light but I see that LayoutAwarePage in Windows Store Apps offers its own basic MVVM implementation. What kind of MVVM implementation is recommended for Windows Store App? It seems that using MVVM Light, I could add redundant code. Maybe it is possible to integrate both systems?

You might also be interested in checking out the Okra App Framework (http://okra.codeplex.com). It is an MVVM framework that is designed from the ground up for Windows 8 development and allows you to still use LayoutAwarePage for the visual states.
Andy

I recently used the LayoutAwarePage in all pages of a project I did recently. I found it to be useful in terms of the its support of device orientation changes,navigation and process lifetime management ie:the windows appstore specific stuff when compare to the blank page. LayoutAwarePages DefaultViewModel is great for a quick and easy way to get up and running but if you are wanting a pure implementation of the MVVM pattern in terms of testablity, loose coupling of components/seperation of concerns and minimal use of the code-behind you are probably on the right lines with MVVM light.
Anyway hope this was helpful and best of luck with you project.
Andrew

Looking to ditch Winforms and start using WPF

Windows Forms is pretty old now, and has been superseded by WPF. I've seen a lot of material regarding databinding WPF layouts, using the MVVM pattern for the applications and some cool animations to boot.
I think it's time for me to abandon the Winforms ship and start using WPF. Once I finish this last freelance project I'll start using WPF exclusively for my Windows Clients.
I have the privilege of having customers with newer machines, so running WPF on their machine won't be a problem. :)
Trying to grab the entirety of WPF is extremely daunting and I feel that if I just dive right in I might keep doing things the Winforms way when in fact WPF has a newer, more succinct way of doing things.
Where do you recommend I start? What are some things you wish you knew before using WPF for production? What book would you recommend that teaches you about WPF (has to be new! nothing from 2007)?

I've just done the exact same thing. I am in the process of moving some apps to WPF. I've decided not to bite off MVVM just yet, or any VM. I'm just trying to learn the basics of WPF. I have found SO, other internet sites and this book very helpful.
BTW, I'm finding it's much easier than I thought. Takes some getting used to, but I'm already hooked (XAML is very cool). I'm convinced the best to learn is to simply jump in and start doing it.

The main advice I can give is to "forget" what you have learned with winforms. Do not try to apply what you did with winforms to wpf... The architecture is quite different and you risk to fall into traps.
Maybe MVVM is not required at your early stages of learning, but its approach make the WPF coding easier than without. Take a look not so late at the MVVM Light Toolkit. This MVVM framework is really light but provide what is required for a full MVVM framework, and only that.
good luck, and do not hesitate to take a look at Silverlight also. The border between the desktop apps and web apps are as slim as ever.

How I'd start teaching someone WPF today:
Make sure they have a solid grounding in XML. If you don't know how to edit XML documents and diagnose and fix problems in markup, you're not going to be able to make progress with WPF. You especially need to be able to work with XML namespaces and understand namespace prefixes without freaking out.
Create an example application that creates a bunch of text boxes and binds them to the properties of an object that implements change notification. Data binding is the fundamental technology of WPF, as far as I'm concerned. Once you understand binding - and it's not that hard to understand, really - the design of things like dependency properties and styles become a lot easier to grasp.
Add additional object types to the application and demonstrate how data templates and template selection work.
Add styles, particularly styles that use data triggers, to the example application.
Add items controls to the example application and demonstrate how items panels and item container styles work. Maybe take a little journey into the different kinds of panels. Walk through how observable collections and INotifyCollectionChanged work. At this point I might possibly create a piece of the example collection that used an ItemsControl with a Grid as its items panel, so that I could walk through item container generation and attached properties.
Refactor the example application to move styles and data templates into resource dictionaries, to demonstrate how resource dictionaries work.
Walk through the design of dependency properties, tying their design back to the concepts we've already mastered. To show this off, I like to add a modal dialog that contains a font-selection combo box for the entire application.
Add commands (using the RelayCommand pattern) to the back-end objects, to demonstrate how commanding works.
Refactor the example application to use user controls.
Walk through customizing a control template.
I don't know of any WPF tutorial that approaches the problem like this, unfortunately.

What i think is most important:
Databinding, one of the most outstanding features of WPF, takes a while to get used to though.
Commands, not sure if there is something like this in WinForms...
DataTemplates, create large parts of the UI on the fly based on data.
Styling, if you need customized controls.
Also you should probably acquire basic XML knowledge if you don't have that already to be able to write XAML (I wouldn't use the designer in VS).

I would heartily recommend the book WPF Unleashed by Adam Nathan. It's how I learned WPF, and I still reference it regularly now, years later. Great introduction that explains things in a clear order, gradually building up skills.
I echo what was said above - forget much of what you know in WinForms. If you try to think of WPF as a "prettier WinForms" you'll not get the full benefit of the platform. Learning to "let go" a bit and embrace Data Binding (SO much better in WPF), and to embrace the idea that controls don't have speficic visuals, then you will be truly free to use WPF to its fullest.

'WPF in Action' is a great book to read before starting any coding. Its very simple to understand and if you have the patience you can go through the entire book in a day or two. It doesnt have any MVVM stuff so for someone coming from a winforms background its great to start with.
Once you 'get the hang' of WPF concepts you can jump into MVVM. Two great MVVM resources I found when learning all things WPF were
1. Video by Jason dolinger
2. MSDN article by Josh Smith

What's are the best readings to start using WPF instead of WinForms?

Keeping in mind what CannibalSmith once said - "All the answers are saying "WPF is different". That's a huge understatement. You not only have to learn lots of new stuff - you must forget everything you've learned from Forms. It's a completely new way of doing UI."
.. and having many years of experience with visual Windows desktop applications development (VB6, Borland C++ Builder VCL, WinForms) (which is hard to forget), how do I quickly move to developing to say well-formed WPF applications with Visual Studio?
I don't need boozy-woozy graphics to give my app look and feel of a Hollywood blockbuster or a million dollar pyjamas. I always loved tidiness of standard Windows common controls and UI design guidelines, end even more I enjoyed them under Vista Glass Aero Graphite sauce.
I am perfectly satisfied with WinForms but I want to my applications to be built of the most efficient and up-to-date standard technologies and architectured according to the most efficient and flexible patterns of today and tomorrow, leveraging interface-based integration and functionality reuse and to take all advantages of modern hardware and APIs to maximize performance, usability, reliability, maintainability, extensibility, etc.
I very much like the idea of separating view, logic and data, letting a view to take all advantages of the platform (may it run as a web browser applet on a thin client or as a desktop application on a PC with a latest GPU), letting logic be reused, parallelized and seamlessly evolve, storing data in a well structured format in a right place.
But... while moving from VB6 to Borland C++ Builder was very easy (no books/tutorials needed to turn it on and start working) (assuming I already knew C++), moving from BCB to WinForms was the same seamless, it does not seem any obvious to me how to do with WPF.
So how do I best convert myself from a WinForms developer into a right-way thinking and doing WPF developer?

Read this questions:
How to begin WPF development?
Is there a WPF Cheat Sheet outhere?
Learning MVVM for WPF
Learning WPF and MVVM - best approach for learning from scratch
MVVM: Tutorial from start to finish?
Download and work through this Microsoft tutorial: Southridge Hands-on-Lab
Check this videos:
Mike Taulty's series of videos
Jason Dolinger on Model-View-ViewModel
And after that, take a look at StackOverflow questions tagged with both wpf and mvvm

Keep in mind that MVVM seems suited only to single window applications.
I dived into WPF based on inexperience and general recommendations that it would suite better a kiosk project, especially one where the customer has given me photoshop images of all the application screens. Having cool graphics was a requirement for this project and I liked the vague resemblance of WPF with web development.
I found out a few downsides
1) there is no such thing as an official MVVM toolkit. There are a lot of them, all backed by an individual. A shot at a toolkit by Microsoft has been put on the back burner one year ago and there is no VS2010 support.
2) programming a multi windows application, sort of a simple wizard with back and forward, is plain nightmare. I got out of this with a clean design defining a delegate for each UI action and a command for each business action, but still I think it is too much involvement with a framework to be justified, and you cannot show the result of your tests to this customer expecting excitement.
3) You give up the habit of double clicking a button and adding some code. This leaves a nagging feeling of using the IDE against its nature. Basically you use Visual Studio as a text editor and an interface designer, still with a great help from the tool.
The upsides, so far are:
1) defining visual components is very flexible, fast and easy and you can choose between VS and Expression Blend. Animations are simple to create.
2) data binding simplifies the application. You define a DataContext and bindings and do not have to move data from the business logic to the interface yourself, as long as you have a property for everything that must be displayed.
3) You can reduce the amount of business logic in the interface to zero. It is easy to separate the application behaviour from its looks, so you can skin your interface in ten different ways with little effort and test all of your logic without opening a window.
4) you leave a door open to going with Silverlight if they ask you.
My conclusion is that if you have an MDI application in mind you might find yourself in big trouble. You should be aware that, if you choose WPF, you are ploughing ground for future generations rather than getting on a train that will get you there fast and easy. There is no established way to do things, especially those that are not covered by demos.
Toolkits, all things considered, are not so important and each of them will serve you well. In fact a couple supporting classes are enough to start and there are no fancy wizards, it is up to you to follow conventions.
You might even make your own if a few hours, once you understand what is involved in the logic. The downside is that you will have to really understand it well to bend the application your own way.
As I said above, I had to learn a lot just to show a new view when they click a button keeping the code clean. Take the time to see the videos cited elsewere on StackOverflow it will save you time.

if you are looking for books just look at this previous post
What WPF books would you recommend?

Having got into WPF this year, the most important thing for me was learning how to use the Model View View-Model pattern for separating the view from the app logic. As a general rule of thumb if you find you are placing a lot of code in the code behind for your view then you are "doing it wrong".
I found that coming from a WinForms background I was putting in lots of event handlers and doing stuff in my code behind. As I became familiar with MVVM and WPF features I found I was able to remove the bulk of my code behind and replace it with views binding to view-models.
It was articles like this one from Josh Smith that helped get me started on the MVVM path:
http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
Once you have started to get the hang of displaying data view MVVM bindings, have a look at commands and specifically the ICommand interface. They are the main mechanism by which actions from the user triggers operations to execute. So rather than having a OnClick handler for buttons, you bind the Command property of the button in XAML to a property in your view-model that exposes an ICommand implementation.
My 2c - Donovan

Try this smashing hit.
Windows Presentation Foundation - Unleashed By Adam Nathan
(source: adamnathan.net)

Learning WPF and MVVM

I have recently joined a new developing project building a thick client application using WPF and MVVM. I have developed applications in various .NET frameworks from 1.1 through to 3.5 and all major technologies; WebForms, MVC and WinForms. On all of my projects I have enjoyed every minute of it but on this project I feel that I am struggling and as such not enjoying it as much. When .NET 3.5 came out in 2008 I really enjoyed learning the new language features (LINQ, MVC, Lambda Expressions, etc) and dabbled in WPF so please don't assume I'm against learning something new.
But the learning curve on this project seems really steep and I feel that learning MVVM on top of WPF + the application is a little daunting. Although I have only been on the project for a short time (2 weeks) I really like WPF but have taken a disliking to the MVVM pattern. My disliking to the MVVM pattern may because I don’t really understand it and I feel that I have to write a lot of “non best practice” code in order to do what was relatively simple in my WinForms days.
So my question is has anyone else faced a similar situation and did you stick with MVVM or go in another architectural direction?

I have been working with WPF since the beta versions and I would never go back to winforms. To me MVVM is a philosophy and it takes a lot of work and discipline to implement it faithfully. It encourages complete decoupling between UI and interaction logic which means no code behind whatsoever which means testable interaction logic which is very difficult to do with winforms.
In contrast to gius I would recommend you stick with plain WPF and MVVM especially if you are just starting out with WPF. There is a lot to grasp with MVVM and WPF, adding to that will just slow down your progress. But that's just my opinion. I always prefer to layer my learning rather than try to learn everything at once that way you are in control and you have more knowledge about how your application works.
If you have not already done so I strongly recommend you read the MS article on MVVM :
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Its fantastic and it is compulsory reading for my team members who write any WPF code.
I am not sure how you and your team work but you need to ask yourselves whether or not MVVM is for you. If unit testing / test driven and decoupled UI is something you are already doing or is important to you then MVVM is definitely a good path to take. If your team is happy with writing code behind and you don't see why you should bother decoupling then don't bother with MVVM as you will find that it will slow you down. Personally the latter is never an option for me.
Please feel free to contact me if you have any specific questions about WPF or MVVM.

I have faced a similar situation, and the route I decided to go was:
Use ViewModels for my views, but avoid some MVVM pureness, like Attached Behaviors (which I find dumb and clunky)
Use Magellan MVC framework, which fit best my mental model about how an applications should behave.

I started learning WPF and quickly came across MVVM - it seemed like such a good fit that I've stuck with it. It's probably worth pointing out that there do seem to be some differences in the ways people implement MVVM, a key one being View-first or ViewModel-first. Some seem to see this as a point of gospel - I don't have enough experience to decide if it should be. I tend towards View-first (so View has a reference to ViewModel and ViewModel has a reference to Model and none in the other direction) but I have come across a scenario where the other way was easier.
Why not post some questions around the specific points you see as non-best-practice. It might help others wrestling with this subject as well.
One other question: are you using a specific framework for MVVM?

Well, before using MVVM, I used MVC in ASP.NET MVC framework. The Model-view-controller architecture is pretty obvious there so it helped me to change my attitude from standard ASP.NET and WinForms.
MVVM is a little bit "harder" to understand, but once you realise that WPF differs from web (you as a user respond back to the view, not to the controller), it makes sense to move from MVC to MVVM.
I suggest reading articles about MVVM on homepage of Caliburn project (left column, part 3. Study in MVVM) - this helped me a lot.
Regarding WPF (Silverlight) applications, I would strongly recommend to start building applications right on top of PRISM (Composite WPF) and/or Caliburn - although it might be confusing from the beginning, still it is a much better choice than with vanilla WPF (speaking about practices they force you to use). But take it for sure that once you have finished your first WPF application, you will want to rewrite it from scratch. But that's how it works when you learn a new technology.

MVVM is just a design pattern. You do not need it unless you are comfortable with WPF. If you are learning WPF, I suggest you first complete the book, then learn about MVVM. If you try learning both, you would try to implement MVVM in every simple WPF app or do not understand some feature of WPF that MVVM uses.
P.S: I came to this conclusion when I faced the problem myself. I still do not understand how the ViewModel can create a new View if it knows nothing about it.

WPF has a steep learning curve. So does MVVM. Which explains the feelings you have: getting to grips with both XAML and MVVM and trying to produce a real-world application at the same time is a daunting task.
I've trained .NET developers like you and helped them go over that learning curve quickly. Then packed that training into a quick-read book that you can get here:
Learn WPF MVVM ebook
Learn WPF MVVM paperback
It's also available on Amazon and major book sites.
Sorry if that sounds like self-advertising, but I really believe this books is 100% appropriate for your profile.