Software Development

Poll: How much code do you put into code behind files?

Justin James discusses his frustration with code behinds in .NET development and explains why he has had a difficult time shifting away from it. Tell us how much code you put into these files.

One of the biggest frustrations I have with .NET development is the code behinds that we see all over the place in different forms. While the code behind model is extremely dated, and smart developers never bought into it in the first place (even with WinForms there is no need to make it more than event handlers hooking to other functionality), the fact is that all of the tooling is dominated by code behind thinking. To make matters worse, using the code behind methodology is much, much faster to get things done than "the right way."

I've had a hard time shifting away from it, because nearly all of my .NET development is maintenance and modification of existing code that's already using it. What about you?

J.Ja

About

Justin James is the Lead Architect for Conigent.

10 comments
joshgranger908
joshgranger908

Im prettey much a bigginner with coding so can someone tell me how to incorperate this in my site?

bmmkumar
bmmkumar

I'm just lucky enough to start my career with the new technology and patterns. For windows application using WPF and MVVM pattern is the best way to eliminate code behind. Commands and Data binding are one such features of WPF which makes the life of developer much simpler to maintain and debug.

Tony Hopkinson
Tony Hopkinson

I voted most of my application logic, but I was thinking of the code behind the code behind, apparently. :p I'm very wary of ignoring speraration of concerns, never seen an instance where it was done, that didn't cause a problem later when a change came along. If a change never comes along then what you did had was of little or no value anyway. It's either dead, or something any cookie cutter could have bashed up.

Kobeny
Kobeny

'...code behind model is extremely dated...' '!???ve had a hard time shifting away from it...' What is the new method then? - asp.net4 newbie

Mark Miller
Mark Miller

Code-behinds are another form of the web forms framework that existed in ASP.Net 1.x. I think a significant part of it is a matter of what the IDE is directing programmers to do. The natural inclination with the IDE is to design the web pages first, visually, and then to put the logic behind them in the event slots that the IDE provides, but I agree, that leads to some really awful code. I used to see this a lot in MFC apps as well. The VC++ IDE offered up a Document-View architecture, but a lot programmers just put all their code in the View classes. I found the only way to break out of this was to become more knowledgeable of the .Net web framework, to think about how you want to structure things, rather than just react to what the IDE directs you to do, and not count on the IDE nearly as much as one is tempted to do. You write a lot more of your own code this way, but it's better code. The attitude that's needed is, "Dammit, *I'm* the designer here!" At least in ASP.Net 1.1 what I did was use the IDE to design web pages, and I used the event slots that the IDE created, but I tried to keep as much of the web form code focused on presenting the data, and getting input from the user, as possible (though I guess I could've split these apart). I kept the data processing logic in other classes and modules. I tried to create something that was more along the lines of Document-View, like in MFC, though I didn't have a single class that I derived off of called "Document." I could've extended this further to delegating page changes to logic in another class, letting my own logic drive the flow of the web app., but I didn't do that, primarily because the apps I was working on at the time didn't have that many pages in them. So the flow control was simple enough that one page could easily decide what next page was needed.

Justin James
Justin James

... concerns me as well. It's a huge boon to unit testing, but it does make hand-debugging and maintenance much harder if you are "parachuting" into a project and do not know where to start. Things magically "just happen" (especially with data binding) and there is no obvious causal relationship involved. Separation of concerns, when done wrong, is MUCH worse (in my opinion) than just shoving everything into the view, but when done right, it is a bit better and has a few very specific advantages. J.Ja

bluemoonsailor
bluemoonsailor

The new method is to use .NET MVC with either an MVC or MVVM architecture. This makes life much simpler. I just finished rewriting a web site from old .ASPX with codebehinds to the newer MVC framework and I accomplished all the same functionality, and a bit more beside with somewhat less than half the code.

Justin James
Justin James

Folks have been strongly encouraged to basically have no logic in the code-behind, other than hooking into event handlers to call into other code, and to use databinding at the declaration level (the XAML for WPF/Silverlight, or in the ASPX for ASP.NET or the view in MVC) to handle things as much as possible... in the model or view model (depending on your architecture) you hook into those databinding events to trigger business logic. J.Ja

Tony Hopkinson
Tony Hopkinson

test (and probably can't have) that would identify the issue. It's starting out with separation of concerns and then breaking it (for sound short term commercial reasons that's the real problem. I've spent most of my career as the guy the people choose to parachute in to a legacy code base. I'm pretty good at it. For that reason on those rare occasions I do get to do something without an existing huge technical debt I am separaion of concerns' biggest fan. It's not just MVC to me, though it's encapsualtion, cohesion, decoupling, those things I've got practiced at coping without....

Justin James
Justin James

At my day job, I spend *very* little time writing code from scratch lately. It's all projects where the technical debt is "extreme" to say the least, and (at least for the last year) it is all code that was written by a third party, under guidance from people in the organization other than myself, so I don't even know what the code is supposed to do. Many times, you need to reconstruct the specs from old emails, and then you discover that the pseudo-spec was rendered irrelevant by a phone conversation two years ago. For better or for worse, this is how most projects end up anyways. My preference is to simply use better tools entirely (this is where I mention OutSystems Agile Platform that I use exclusively now for my side projects) in which the technical debt in these situations carries a MUCH lower interest rate, late payment fees, and non payment fees. Using that system, parachuting into a project isn't nearly as bad, not only do you get oriented much quicker, but your understanding of what is going on is much more accurate. J.Ja

Editor's Picks