Tutorial :is “non-intrusive code-behind” a good or bad practice?



Question:

I am a bit surprised that while learning WPF/XAML/Silverlight almost all of the XAML/C# examples I have encountered have the "Click" events in the XAML and very few in the Window or Page constructor.

With all the emphasis these days on "non-intrusive Javascript", I would think that more developers would actually be structuring their XAML/code-behind like this:

XAML:

<Grid>      <Button x:Name="btnEdit"/>  </Grid>  

Code behind:

public Window1()  {      InitializeComponent();        btnEdit.Content = "Edit";      btnEdit.Click += new RoutedEventHandler(btnEdit_Click);  }    private void btnEdit_Click(object sender, RoutedEventArgs e)  {      btnEdit.Content = "This button was clicked.";  }  

Any thoughts on why this would be a good or bad practice?


Solution:1

Most of the smaller WPF examples give just an impression what is possible without focusing on design issues or good style.

In real world applications XAML should only be used for declarative programming. For example, binding a command to a button or declaring a data binding. Karl Shifflett has some great articles about the MVVM pattern which separates the concerns of your WPF/Silverlight application very well.

Code behind is in my opinion just suitable for tiny applications. It tends to mix view, control and data.


Solution:2

If I remember correctly, I think that there is a partial class which implements the Init code above that is code gened by visual studio. I can’t speak for WPF, but it does this in ASP.Net 2.0, so I’m assuming that it does it the same here. It took me forever to get used to this.

I agree. I hate defining events in the markup.


Solution:3

I agree with your concern.

After much debate, we are following a similar pattern of non-intrusive, ultra-lean XAML and binding commands and data in code-behind.

If you add events in the XAML there is a contextual menu navigation to the event code. If you bind commands in XAML there is no equivalent. You can navigate from the command declaration in the XAML but not where it is assigned to the Command property on a control.


Solution:4

MVVM is bad practice. You think that you separate Data and View. And what? Total mechanism with XAML binding, binding commands, translating it to methods and implementing INotifyPropertyChanged for what? For UTests (I made - I test conception he-he)? Right software need in only in user's test... It's your code separated in such way in which you sometimes do not understand where is what.

For what you use INotify? For what Microsoft ALL WPF controls and entities as whole in WPF wrote inherited from FrameworkElement with magic DependencyProperties?

Multiple binding is hard resource technique by the word (read authors of MVVM).

I wrote high complicated 3D CAE system without any Patterns less than year... with classic organization of app with classes and code-behind. https://skydrive.live.com/?cid=ea6ad1087e3103f0&sc=photos&id=EA6AD1087E3103F0!103&sff=1#cid=EA6AD1087E3103F0&id=EA6AD1087E3103F0!118&sc=photos

All the samples in MVVM are about Customers in Company... I offer put the name MVVMCC pattern (Customer in Company)


Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »