WPF with code only

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 desig开发者_运维技巧ner 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.