如何将接口与代码分开？

Question

I know that I will be downvoted for this is kind of abstract question. I am aware that I'm missing the necessary specificity but this is a very important question to me.

I've been a WinForms C# user for ages. Now for work necessity I've been required to migrate to WPF. But what is puzzling me now is: am I using it properly? And specifically am I dividing xaml interface and code properly?

As a rule of thumb I put in the xaml interface all what I can and particularly all what's defined before hand. On the other hand I'm letting in code behind all what's programmatically defined. Is that correct?

And then what are the advantages of putting all what I can in the xaml interface?

Answer 1

Write just as little code in the code-behind files as you can. most of the time, you can get away with zero lines .

To react to UI-induced events, you should use the Commanding mechanism . This will call a method, not in your Code-behind, but in a View-Model .

Then you should google a bit on the MVVM topic.

The reason why you want to separate your logic from your code-behind is so that code-behind is all about UI.

if you have calculations to perform, you should not mix those concerns with the presentation layer.

For instance, you could want to have all your calculation in a portable library in the future so you could have a Windows phone version of your app, or a web-based service, or replace some heavy computation by a web-service.

The yes philosophy here is to embrace SOLID principles, and WPF just promotes its use and allows to make cleaner separation for a better re-use and maintainability.

Answer 2

There is nothing wrong with code-behind as long it doesn't contain program logic. UI events and UI related code (for example: closing window or opening a new one) works perfectly in code-behind, and should be used there.

The principle behind MVVM is to decouple UI specific routines from your business logic and functions.

Also a very important rule to keep in mind is that the viewmodels you create should be able to be reused in lets say asp.net site, windows mobile app or universal windows app. So there's also no need to be UI aware. A lot of times I see implementations where people glue the view (ui) and viewmodels together inside one project to overcome some limitations of viewmodels. This is however bad practice and defeats the main purpose to decouple your view from viewmodels and allow actually to reuse your viewmodel in other projects.

To my students I advice therefore to start your viewmodel as portable class (this enforces you not to use ui elements inside your viewmodel) and depending of your view to extend them with platform specific functionality.

Reusing your viewmodels is then a breeze.

As glue between Viewmodels and views I recommend to use Prism Prism Project page and Nuget package