Return to Answer

Tried to clear up any misconceptions that I was arguing against xaml; added 118 characters in body

edited Feb 17, 2011 at 15:28

221
2
7

One of the biggest advantages to doing everything you can in xaml is that it keeps all of the behavior in one place. Every time the developer has to jump between the xaml and the code it becomes more difficult to understand it.

I've been on a WPF team that didn't make reduction of code-behind a priority. There were more than a few times that debugging was much more difficult because some event handler was manipulating the control and it wasn't immediately apparent because the behavior was scattered around in two files.

That said, I believe you are right to think that sometimes you are better off compromising on the design principle. Some things are very difficult to do in xaml. I've spent hours or even days trying to get a behavior to work in xaml that I could have done in much less time by using code-behind. I've come to treat code-behind as a last resort, but I would never tell someone that they should never use it. It's just another tradeoff that a good engineer needs to understand.

edit: From the comments it sounds like my post is being interpreted as arguing against xaml. My intent was to argue the opposite. Pure xaml is always preferable because it keeps all of the behavior in one place. A mix of xaml and code-behind can get convoluted, so minimizing code-behind is ideal. Xaml is preferable to pure code-behind for lots of reasons. WPF and Silverlight are designed to be written in xaml.

One of the biggest advantages to doing everything you can in xaml is that it keeps all of the behavior in one place. Every time the developer has to jump between the xaml and the code it becomes more difficult to understand it.

I've been on a WPF team that didn't make reduction of code-behind a priority. There were more than a few times that debugging was much more difficult because some event handler was manipulating the control and it wasn't immediately apparent because the behavior was scattered around in two files.

That said, I believe you are right to think that sometimes you are better off compromising on the design principle. Some things are very difficult to do in xaml. I've spent hours or even days trying to get a behavior to work in xaml that I could have done in much less time by using code-behind. I've come to treat code-behind as a last resort, but I would never tell someone that they should never use it. It's just another tradeoff that a good engineer needs to understand.

One of the biggest advantages to doing everything you can in xaml is that it keeps all of the behavior in one place. Every time the developer has to jump between the xaml and the code it becomes more difficult to understand it.

I've been on a WPF team that didn't make reduction of code-behind a priority. There were more than a few times that debugging was much more difficult because some event handler was manipulating the control and it wasn't immediately apparent because the behavior was scattered around in two files.

That said, I believe you are right to think that sometimes you are better off compromising on the design principle. Some things are very difficult to do in xaml. I've spent hours or even days trying to get a behavior to work in xaml that I could have done in much less time by using code-behind. I've come to treat code-behind as a last resort, but I would never tell someone that they should never use it. It's just another tradeoff that a good engineer needs to understand.

edit: From the comments it sounds like my post is being interpreted as arguing against xaml. My intent was to argue the opposite. Pure xaml is always preferable because it keeps all of the behavior in one place. A mix of xaml and code-behind can get convoluted, so minimizing code-behind is ideal. Xaml is preferable to pure code-behind for lots of reasons. WPF and Silverlight are designed to be written in xaml.

answered Feb 16, 2011 at 16:25

221
2
7

One of the biggest advantages to doing everything you can in xaml is that it keeps all of the behavior in one place. Every time the developer has to jump between the xaml and the code it becomes more difficult to understand it.

I've been on a WPF team that didn't make reduction of code-behind a priority. There were more than a few times that debugging was much more difficult because some event handler was manipulating the control and it wasn't immediately apparent because the behavior was scattered around in two files.

That said, I believe you are right to think that sometimes you are better off compromising on the design principle. Some things are very difficult to do in xaml. I've spent hours or even days trying to get a behavior to work in xaml that I could have done in much less time by using code-behind. I've come to treat code-behind as a last resort, but I would never tell someone that they should never use it. It's just another tradeoff that a good engineer needs to understand.