Dec 17, 2010
If the code behind is the best thing ever ( I agree it is ) why Microsoft invented the new way to binding, trigger ...etc. from xaml markup. That is because there is somebody will need it. Also less code is less bugs and less code to maintain.
plus if you use code behind you will miss xaml deploy only to deploy a WPF App which is require to have only xaml file to deploy the WPF app thru the browser.
That is my salt as well J
Dec 20, 2010
Just a short follow-up. What MVVM also gives you is that it will be easier to test. Testing
business logic in code-behind is a PITA. However separating the logic with MVVM pattern
will make it easier for you to test your business logic. Another benefit is that it will also
make it easier (hopefully ;-) ) to swap out your UI (Views) in the future if that is needed.
But, some UI specific code is better of being added in the code-behind. And you seldom
add tests for UI specific behavior.
Dec 06, 2010
MVVM is a architectural design pattern, that basically describes how to separate UI from logic. It does so by promoting that you put logic in your VM. It does not say anywhere, that I'm aware of, that you shouldn't use a code-behind file nor does it say that you should never put code in it.
I use MVVM but still have a code-behind file. For instance, it is an ideal place to put UI specific code, which could be somewhat difficult to do in the VM.
Some use the code-behind file to set the DataContext when doing data-binding (I use Xaml & Behaviors with Unity for this though).
You could probably pull of a code-behind free application. But the question is, is it worth the extra effort?
Just my 2 cents
Dec 07, 2010
Wherever you go as a .NET developer, there are always those with extreme viewpoints. Indeed, you could write your WPF MVVM applications without any code-behind. However, if that is such a good thing why is it then that Microsoft still offers the option for code-behind? Apparently, someone is still using code-behind (in fact, all .NET developers that we know).
I remember, about 7-8 years ago code-behind was marketed as the greatest thing: it would separate concerns and remove the code from the HTML in your ASP (note ASP, not ASP.NET).
Anyhow, we think that totally removing code-behind is an extreme position. It is like telling someone not to eat salt. True, you can live without salt, but would that be any fun or easy to do? My suggestion is to take everything you read with a grain of salt (no pun intended) and do what works best for you.
We at DoFactory, use litlle salt, but we are not salt-less; in other words, we embrace MVVM and in doing so we like to keep our code-behind files light-weight.
Anyhow, I hope this clarifies our viewpoint.