Related
I have a little program which I made with WinForms and now I want to make it again using WPF.
I'm new to WPF and I read that whatever you can do with XAML, you can also do without it, meaning using code only.
Of course that you don't have any XAML when using Winforms. Can I use the same code for the WPF application that I used for the winforms application and get the same result? Or do I need to create and edit XAML? What are the advantages of using or not using XAML?
Also, considering the past experience using Winforms, should I somehow change the way I'm thinking about design and implementation that worked for Winforms but are not that appropriate for WPF?
No you can't reuse code from winforms in WPF.
and even if you could, you shouldn't.
whatever you can do with XAML, you can also do without it
You should really use XAML to define the UI, and then use DataBinding and MVVM, which is a much more professional way of development than the traditional procedural winforms approach.
Not using XAML is much more troublesome than using it. It may look intimidating at first but it's a really awesome thing to work with.
Of course that you don't have any XAML when using Winforms
No, of course not. winforms is a really old technology that doesn't support anything. That's why they created the Visual Studio designer, otherwise no one would have ever used winforms for anything, because of the horrendous gargantuan behemoth amount of code required to do anything useful.
Can I use the same code for the WPF application that I used for the
winforms application and get the same result?
Probably, by adapting some class names and whatnot, but then you lose the main advantage provided by WPF, which is precisely getting rid of the horrible winforms-like code.
considering the past experience using Winforms, should I somehow
change the way I'm thinking about design and implementation that
worked for Winforms but are not that appropriate for WPF?
Yes. WPF supports MVVM, and that requires a really different mentality from the traditional winforms approach.
I strongly recommend reading Rachel's Excellent Post about upgrading from winforms to WPF.
I tried converting a Winforms app to WPF directly, and it causes way more issues than you need because you are fighting the framework all the time. Read up on MVVM and databinding and use that. Its what WPF is designed around, and comes with several advantages such as testability. You can actually get quite a long way with a few of the simple concepts (databinding, viewmodels etc...) and expand your knowledge as you go, but I'd recommend an understanding of MVVM and databinding in WPF first.
A good framework to get started with would be MVVMLight, but its worth writing the basics without a framework to get to know how things work first.
I seem to remember this being a good set of posts from reed copsey: http://reedcopsey.com/series/windows-forms-to-mvvm/
Trying to create WPF controls without XAML is asking for trouble - the whole framework is built around the MVVM pattern which demands that your View be described in a declarative fashion, rather than a procedural fashion. While you can definitely create same UI objects in C# and XAML, doing so in C# will require you to know (in truly excruciating detail) how the framework operates in order to compensate when the state of your UI changes. On the flip side, if you do it XAML (as WPF dictates you are supposed to), then things generally update just fine and without the necessity of working around endless bugs. In short "yes" you can do it in code, but "no" you can't do it in code without losing your sanity.
Actually it depends on how complex is your project. For quite a small project you can make this "conversion" quite simply. But it's not a good practice even because WPF development often is based on MVVM/Prism and they give you lots of advantages.
Also the behavior of your UI might be different - it depends on the complexity of your project.
I'll 2nd or 3rd or 4th the other answers. Never, ever, ever, ever, ever try to build a WPF app with "Winforms style" code. I did that on my first ever WPF app and it was the biggest mistake I've ever made. What a gigantic mess. The 2nd app I went half-way towards MVVM and that too was a gigantic mess. 3rd app and ever since I've gone 100% MVVM, DI, etc. and 100% by the book WPF and code is super clean.
There isn't really a point in porting Winforms code to WPF any way. The majority of the code you wrote in Winforms is thrown out when you go WPF. Basically the only portable stuff is the business logic. All the UI logic is completely different.
And you'll thank us later because one of the greatest concepts ever about WPF is the separation of UI and business logic. That makes swapping out controls a piece of cake.
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
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)
I've seen a lot of questions about the merits of WPF here, and essentially every answer says it's the bee's knees, but essentially every answer also talks about things like XAML, in many cases graphic designers and Expression Blend etc. My question is, is it worth getting into WPF if you're a solo coder working in C# only?
Specifically, I don't have a graphic designer, nor any great talent in that area myself; I don't use point-and-click tools; I write everything in C#, not XML.
Winforms works fine in those conditions. Is the same true of WPF, or does it turn out that important functions can only be done in XAML, the default settings aren't intended for actual use and you have to have a graphic designer on the team to make things look good, etc., and somebody in my position would be better off to stick to Winforms?
I'm a code person myself, and to be honest, it doesn't matter. Even if you don't know anything about graphic design, you can still use the editor in visual studio to design an UI. The designer features an drag&drop designer as Win Forms does, so that doesn't really pose a problem. Even though I'm a code person, I have no problem with xaml, as it is, in some way, code again. I had problems with the xaml at first as well, but I got used to it, and stuff I had to do in code in Win Forms was quite easy in xaml.
Databinding simply rocks, you don't have to care about getting the data to the UI, you simply have an ObservableCollection<T> or similar, and one Property in the xaml code and everything gets done for you. Want to format the data? Simply add a formatting property to the binding. Want to color the text according to the value? Template Selector class with 15 lines of code, Binding and Template selection in the xaml code of about 10 lines. I'm really growing to love it, and with time (as with any other new technology) you get used to it, and produce good looking stuff.
Short answer: is yes, you can do WPF with code only.
Longer answer: The part about a designer being able to work on the UI and a developer on functionality is really just a side-effect of decoupling functionality from presentation.
What WPF brings to the table in a powerful way is data-binding which enables you to use wider range of design patterns. MVVM has been discussed quite a bit recently.
The various MVVM framework encourage convention over configuration allowing you to write less code to accomplish the same goals.
This decoupling also has the nice side effect of making your application more testable (you don't have to write tests if you don't want to, but at least the option is there).
Moving to WPF from WinForms will most likely be worth it for you for new development. You could in theory keep doing what you've been doing with WinForms (just with new libraries), but it gives you the option to incorporate newer tools into your development as you become more comfortable with technology.
If you haven't seen it already, the BabySmash series by Scott Hanselman is pretty interesting.
IMHO, it is worth going the WPF route if only to ensure that you build these skills. I have toyed with Silverlight which is XAML based and I could transfer much of that knowledge to WPF even though SL is a subset.
And to be honest once you get used to it, most UIs are build just as easily with WPF as with WinForms. And the tooling is quite nice, using SketchFlow for prototyping is useful, and does not require you to have any real artistic skills other than what you have for doing WinForms stuff. I believe going forward, it would only benefit me to be learning more about WPF, and I believe that would be the case for others.
Everything that can be done in XAML can also be done in code due to the fact that XAML is merely a DSL for instantiating and configuring graphs of objects - specifically those in the WPF library (System.Windows). If you're building line of business apps, then there's very little that WPF offers that isn't available at all in WinForms. The key difference is that WPF allows you to do many things much more easily and flexibly, due to its more advanced object model.
I think that WPF is certainly worth learning, but if you want to do it without learning XAML, then I think you'll probably find it more difficult grok.
It's also worth considering that many WPF developers write the XAML by hand (whereas their designer counterparts will be more likely to use Blend in the first instance) partly through necessity (the WPF designer prior to Visual Studio 2010 wasn't very good) and partly because the object model lends itself to a more concise expression in XAML than in C#. XAML is itself quite a small language but the object model it is used to define (the WPF object model) is huge - and that's where the complexity comes from.
If you have no compelling reason to stop using WinForms, then don't. However, if you can push aside your preconceptions about writing code in XML rather than C#, then I think you might be surprised how this different approach to building a UI might clean up your code.
I say WPF can be for you, and if you don't want to go the xaml way and do code only you should go ahead and do that, in xaml certain thing are impossible but it is the preferred way of doing layout, but no one forces you not to do it in code, however if you learn xaml you will produce UI elements faster, then you would in code, so that's something to remember.
this is an old post but...
To my opinion, there are no bounderies when you code by your self in any environment and that always something needs to be discovered. People have created layouts in code for many years in the past, but certain factors moved the community to create graphic and ui tools. But again, nothing lasts for ever and trends change quickly. Also remember the transition from ASP inline coding to layout composition style of ASP.NET and then back to inline with ASP.NET MVC. Was it a step back? Certainly not, because it was supported with other techniques and tools like razor, dynamic language, model binders and more.
So, actually noone can tell you the right way to work as long as you follow basic rules and standards and realise that it's not just code but rather today's code, with all the lambdas, linqs, expressions, anonymous, DLRs etc.
Who knows? Maybe you will be the one to create a new way of expressing and driving content.
I don't like to use XAML. I prefer to code everything in C#, but I think that I am doing things wrong.
In which cases it is better to use XAML and when do you use C#? What is your experience?
Creating an entire window in C# can be a mess of code. The best thing about WPF is that XAML allows you to separate your design from your logic, making for much easier-to-read code.
I'll use C# when I need to create dynamic controls, but I tend to keep my general design, static storyboards, styles, datatemplates, etc. in XAML.
Check out this video on MVVM in WPF. If you want wrap your head around how to organize a WPF application vis-a-vis what goes in XAML, code behind and other abstractions, this is a great place to start.
You can certainly go too far with XAML. Those who want their entire user interface (including logic, event handling relationships, etc) defined in XAML are probably missing the point.
The aim of XAML is to provide a common format for determining how things should look. It should just be a description of how to lay things out, how to color and style them visually.
There is really very little point in trying to use it as a replacement for other aspects of C#, because C# has a permanent head-start in terms of programming features - reuse (defining types and functions), referring to variables, procedural programming, and even declarative or functional styles.
Personally I really like throwing together a UI with a Linq expression!
The ultimate absurdity was reached by a sample I saw where they used workflow actions as the children of a button to supply the Click handler, so the whole program was in XAML. It sounds "cool", but the problem was that it was significantly more ugly and unreadable than the equivalent C# or VB.NET program, and so everything that is ready to use in C# has to be replaced by a more verbose, flaky equivalent. Nothing has actually been gained by this translation to an uglier syntax - it's the same program only more hideous. XML is a poor basis for the syntax of a general programming language. Start with the fact that the greater-than symbol has to be written as >!
In a parallel universe, Microsoft released C# 3.0 before they finished XAML. The XAML team adopted C# 3.0 object/list initializer syntax instead of XML as their syntax. And this whole debate never happened.
My experience is that some things are far quicker to do in C#, while most are quicker to do in XAML. When it takes 5 lines of C# code to do what a single line of XAML code can do, it's pretty easy for me to choose which is better.
Basically, XAML is meant for expressing visual-design, C# is meant for expressing logic.
Any visual design should be done in XAML, any logic should be implemented in C#.
- This enables giving the visual design to a designer to play on without worrying about changes to the logic and even replacing the entire visual design at run time using loose-XAML.
- This also means you could replace either the logic or the visual-design without "breaking" either.
- The connection between the two should be done with data bindings and with command bindings.
The practice I use is:
1. Define the model (the business data object model) in separate C# code.
2. Define the constant parts of the view (the constant parts of the graphical user
interface, e.g. the windows, menus, ...) in XAML (preferably use Blend and not VS for this).
* Do not define styling (colors, fonts, ...) here.
* Do not write event handlers for buttons (in most cases) in code-behind-the-XAML, use command-bindings instead.
3. Define how the model is presented within the view (the GUI for viewing/editing the data objects) using XAML "ResourceDictionary"s located in separate files.
- Write using blend then add bindings to XAML using VS (Jetbrains' Resharper add-on for VS will help with binding expressions).
- If the object types are not known during design-time you can use "loose-XAML" and place the XAML in a folder which can have files added to / edited within without recompiling.
4. Create a connection between the model and the view (a controller/view-model) in C# which:
* Creates views as necessary (for dynamics objects)
* Data-binds the view to the model (sets view's DataSource as the relevant object within the model)
* Implements the commands
* Command-binds the view to the command implementations within itself
5. In Application.xaml delete the StartupUri="MainWindow.xaml" and add Startup="ApplicaitonStartUp" instead.
Within the ApplicationStartUp() event handler:
* Load any loose-XAMLs you have
* Create the controller
* Create the main window
* Create the model
* Connect controller to model and main window
* Show main window
* (Save model, controller and main window into private fields here to make sure they are all kept alive)
6. Add styling (colors, fonts) to a separate XAML file under a ResourceDictionary (using blend for this or purchase a ready made XAML theme/skin file).
The urge to want to write your UIs in C# instead of XAML is really just a manifestation of how comfortable you are in XAML.
For me, is is a personal goal to write as little code-behind as possible. Quite simply put, code behind is hard to unit-test, but can (and usually does) include logic that doesn't get tested. XAML is declarative (like HTML) and doesn't include any logic, so there is nothing to unit-test. I keep my view code in XAML and I keep my view logic in my ViewModel (MVVM) which is VERY easy to test.
Once you become more comfortable with XAML, the more you will realize its benefits over view construction in procedural code... Using a pattern like MVVM, you take it a step further, and realize that code-behind is only useful in rare cases.
The most important thing to bear in mind is that XAML is for presentation. All your presentation should be in the XAML. If you have logic, you keep that out of your XAML - in your C#.
Imagine swapping out your XAML file with one that LOOKS completely different - but still uses the same data - that's where the division should be.
One of the nice things about XAML is the separation of presentation an logic. This separation is not just theoretical but also practical. I my case, most of the my UIs are now being handled by a designer. This designer uses blend and does not know C#, has no interest of learnning c#, and frankly should not need to. This designer is a true designer, an artist, that knows how to use those tools to make things look really really nice.
Basically my phylosipy is this, the more I use XAML, the less work I have to do on the UI because he can do it. This has worked well for us. I usually design my control to be lookless, give them a basic no frill look, use the DataContext to bind my object(btw DataTriggers are a great way to cut down on code). As a result, I will often checkin my code, come back the next day, synch it, and the UI will look completely different, but everything still work!!!
Of course, it took at least 1/2 year to get there, but now this model seem to work and our UI look Kick A##, our application earns high praise, and I do little work on the UI itself and get to work on cooler things. To make a long story short, I think the code behind might be a bit more developer centric and forgets a whole other group that can benefit, trive, and make a living using WPF, namely the designers.
Of course, there are still times when it takes a devloper to make XAML/WPF sing and dance, and sometime we need to educate the designers about the right way to do things, but I think its worth the investement pays off many times over in large scale projects (maybe not so in short one0
XAML , MXML all these stuff works as long as you are developing a simple UI with some average complexity . Once your UI gets complex and richer , the automatic data bindings will cause more trouble than their benefits . The purpose of XAML is not make programming easy , it is to seperate UI from logic so that tooling of UI can be easy ..
No Data bindings , No Event handlers .. assume that you will never see your XAML again and write code ..
XAML is presentation . Data binding is not presentation . its presentation logic. put all presentation logic in code behind (data binding and handlers). Developers own code behind , Designers own XAML . if you are a developer and if you are touching XAML , then move that part in to code behind .
we can write WPF apps without XAML too ..
Thanks
Vinoth Kumar R
(Had gone thru enough using Flex MXML data binding)
It's not just about you, it's also about your team, some of whom may be designers.
XAML and C# is a really good way to separate the logic from design as already described.
For a typical programmer the way of programming is really changed by using WPF, assuming that the programmer comes from a C++, VB, WinForms, ATL and MFC background, a background from were the UI was not as natural separated from the logic as with XAML and C#.
To get used to this way of programming it takes some time, but getting more and more experiance it gets really effective.
Before starting it is really good to learn the MVVM pattern and to run tutorials to understand the strength of the pattern, and also to get to understand its benefits.
WPF and C# applications based on MVVM pattern benefits:
1. User Experiance and Usability
Separating the logic from UI, makes it more natural to have a dedicated designer working on the UI design and animations. In that way the programmer can focus on the logic behind and the technical solution while the UI is designed by someone that knows design.
That has been a problem for many software companies, atleast in the industry that the programmers actualy are the once that are designing the UI as well and that has resulted in a lot of support, maintance and in effecive applications.
There is a higher probability that it ends up with more user friendly applications by have a person with Usability background focusing on the usage instead of the technical solution. There is really interesting book abbout such examples, User Interface Design for Programmers, by Joel Spolsky.
By using the MVVM pattern for XAML application there is a good chance we will see more user firendly applications.
2. Maintanence
Maintenance, which is cost a lot within software development.
It can feel that the MVVM pattern is a big overhead in the begining but while functions are added and the more complex and advanced the application is getting the more benefitial it is. You will see that it is really easy to maintaine such an application.
For an overview you can look into this video:
3. Mix of competences
Dedicated designer and a dedicated programmer working in a team to achieve a better result is a very good way of mixing competences. Instead of only hiring programmers organizations need to combine the competences to provide the best results.
4. Opportunity for design interested programmers
Finally it is possible to implement fancy applications in the Windows environment. If you are a programmer that are interested in design the Microsoft Expression Blend really opens up possiblities to learn and achive fancy, useful applications with a nice design.
There can though be risk using with XAML and C#, MVVM or not, the great possibilities and flexibility it provides can also be a drawback. Letting the programmer loose with this new easy UI environment, the applications may end up with a wide spectra of animations, colors, everything this new environment provides. Remebering how you added UI controls in the C++ and ATL envrionment.
Still the benefits are more and I hope you get some inspiration to use XAML instead of C# for the UI, when getting used to it I am convinced you will like it.
A link to a good tuturial:
Tutorial MVVM XAML C#
I originally came from the Web side of development and am learning WPF/Silverlight at the moment. For me, the XAML model makes much more sense to me than WinForms ever did. I treat the XAML as if it were HTML and the .cs files just like a code-behind.
I love clean code, the less code I have, the cleaner it is. Code can be written in millions of ways, XAML is more restrictive. XAML is good at cutting down code, when appropriate of course. If I can put something in XAML, I'll do it. Tools can read XAML and do stuff with it. Much less with code. Tools and frameworks handling XAML will evolve and get better, doing more and better work with existing XAML. Can't say that about code. The more XAML evolves, the more we'll be able to declaratively define our applications.
For me, using XAML is like using LINQ. If I can write a one line statement that is easy to read and let a framework decide the best way to implement what I want, I feel good. I definitely try, as much as I can, to use declarations of what I want instead of hardcoding how I want it to be done. F# is another good example of this paradigm.
All logic should be in code regardless what you programming language that you use in computer programming. XAML should never replace that even in ControlTemplate although it is nice but it is far much easier to unit test and debug code.
It seems no answers mentioned an important point yet:
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465340.aspx
XAML is just procedural code (only easier)
<Grid x:Name="ContentPanel" Margin="12,0,12,0">
<Button Height="72" Width="160" Content="Click Me" />
</Grid>
"The following shows how this XAML could be partially replaced by code written in C# or Visual Basic."
// Initialize the button
Button myButton = new Button();
// Set its properties
myButton.Width = 160;
myButton.Height = 72;
myButton.Content = "Click Me";
// Attach it to the visual tree, specifically as a child of
// a Grid object (named 'ContentPanel') that already exists. In other words, position
// the button in the UI.
ContentPanel.Children.Add(myButton);
If you worked with windows forms for example, you probably remember the windows forms designer generates a .designer.cs file containing code similar to the example from the link above. That kind of declarative code is much better represented in XAML than C#.
For any non-toy application you should ALWAYS prefer XAML to define UI and connect it to logic in a MVVM manner.
Some things are easier to maintain or debug in code.
Not to Mention that you will be able to do more in Xaml2009 that has to be done in code behind now.
Unfortantly BAML won't fully support xaml 2009 in vs 2010 time frame so you can't compile xaml in 2010 time frame. And will have to wait for a later version of blend to do the full dev design loop. (later than 3)
Douglas
XAML can be seen as being similar to a combination of XHTML and CSS or XML and XSL which are used for structure and design. Any form of logic should be in C#. This way structure and design are seperated from logic. Your code should be cleaner too by using this approach. Another positive thing is that tasks can be easier to separate between designers and programmers.
One more thing... this is the definition of XAML from MSDN:
Extensible Application Markup Language (XAML) is a markup language for declarative application programming. Windows Presentation Foundation (WPF) implements a Extensible Application Markup Language (XAML) loader and provides Extensible Application Markup Language (XAML) language support for Windows Presentation Foundation (WPF) types such that you can create the majority of your application UI in Extensible Application Markup Language (XAML) markup. In addition, the SDK includes a Extensible Application Markup Language (XAML) editing tool called XAMLPad. You can use this tool to experiment with Extensible Application Markup Language (XAML) in real time.
Link to quote.
Programming WPF in C# with a fluent style helps keep the code size and complexity down. See this answer for an example of using a fluent style with WPF.
It's mostly preference I think. I use WPF, since it's easier to structure different screens and separate the C# code logic from the UI. Typically all my logic is structured in another C# library than my UI which is the startup project in WPF or Windows Forms