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.

Advice on MVC pattern for WinForms app

I'm writing a Windows version of my Mac app (C# Winforms) and would like some advice on what design pattern to use.
My Mac app uses an MVC pattern with Core Data for storage. This is a simplified diagram of the models and relationships:
The desktop app collects logs on a background thread and periodically uploads them to my web app. The database is used to store both the user's account information and logs, and the app has a 3 views to display (and collect) the user's data.
I've done some reading and it seems that MVP is the recommended design pattern for WinForms apps, but I'm not sure how to proceed from here. I think that my app is simple enough to write without using an external framework like MVC# but as I have never made a WinForms app before I am only speculating.
Can someone recommend the best way to go about this?

Patterns are really just guides as to what problem it is trying to solve. Where an MVC would work well for a web app that relies on pages and redirects etc a winform app can benefit from using MVP.
Having said that the two patterns are siblings of a wider UI pattern and even according to Martin Fowler the MVP pattern can be further split. Look at his article to get a good feel for the appropriate pattern. He has broken the MVP to Supervising Controller and Passive View. Even the new MPF MVVM pattern is actually based on the PresentationModel pattern.
I would say look at the patterns and see what fits rather than trying to use a pattern because you used it in another scenario.

In my experience for a winforms application (which supports nice databinding) you can use MVC with a supervising controller pattern. Read through this question What are MVP and MVC and what is the difference? & http://codebetter.com/jeremymiller/2007/05/25/build-you-own-cab-part-3-the-supervising-controller-pattern/

You should take a look at Jeremy Miller's Build your own cab series :
http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/

Start to work on it, do some screen mockups, do some design, write some code.
You could start with a few small prototype, try out different design. Don't go too far in your exploration phase so that you don't hesitate to throw it away and start over if you need.
Try to keep your choice open as much as possible, don't paint yourself into a corner, and delay this decision until your really need to choose one way over another.
By then you will probably have a much better Idea of what you need.

Composite Application Block - Is there a suitable replacement available?

I have two very large WinForm applications built on the now dead Composite Application Block ("CAB") from Microsoft Patterns & Practices. I was an earlier adopter and jumped in first to embrace and use CAB. Well, now that it's truly dead I'm starting to think more and more about the future and what framework I can migrate to.
What I like about CAB:
* Structure, structure, structure - I lose focus easily and tend to suffer from "analysis paralysis". CAB introduces a "way to do things" and that keeps me on track and developing the application instead of worrying "how to wire up events, or what the best IoC is, etc.
* Actually... I think that's about all that I really like about CAB ;0)
I have seen articles about "build your own CAB" but I'm not interested in that. I'd really like to jump ship to a similar framework that is solid and actively supported. My web searches have not turned up anything that seems to serve the same needs as the CAB did. Maybe it's that everyone DOES build their own and that's why there isn't another framework out there.
If you have some guidance or advice I'd really like to hear it.

You can check out the
Smart Client Software Factory
OR the
Web Client Software Factory
I am not sure about specific features / patterns that are targeted by especially the SCSF v/s the CAB but i have been using WCSF for a while now and it definitely provides the structure that you like about CAB.
I believe these two do constitute the prescribed guidance from P&P and are definitely being updated.

I would suggest you porting your app into WPF - PRISM. I wish they had a PRISM way for Winforms too, but sadly they dont. We had two of our last enterprise level applications migrated using SCSF, now we have switched over to PRISM for the obvious reason. It does include initial learning curve, i knew wat WPF was and had my Helloworld app done with few extras. but now since we had to switch to PRISM WPF, i am having the steep learning on both! Good luck!

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.