The great ASP.NET code-behind debate

Takeaway: To be inline or not inline, that's a question ASP.NET developers often debate in regard to their coding practices. Find out the reasons both sides give for their chosen path, and decide whether codebehind beats inline code.

Visual Studio .NET (VS.NET) provides a very intuitive Web development environment for Visual Basic developers. VB developers have been trained for years to drag and drop their visual interface on the design surface and then double-click on an element when they want to write code that controls it. I think one of the crowning achievements of VS.NET is the way that it has taken the Windows software design and message loop paradigm and mapped them to a stateless environment like the Web. Once you begin writing production applications, you quickly find that the mapping isn’t perfect, but VS.NET’s ability to bring Windows programmers into Web development quickly is nothing short of remarkable.

Of course there are a lot of Web programmers who learned to write Active Server Pages using Visual Interdev, Visual Notepad, or other Web-development tools. Many of these developers have had a difficult time adjusting to the VS.NET world. They’re used to breaking down their applications into a series of ASP pages, which encapsulate both the visual interface and the behavior for that interface.

If you look at many of the code samples from the .NET beta days that were written by ASP developers using the Framework SDK (before VS.NET was ready), you'll see primarily inline code examples. That’s because they were accustomed to coding that way from their ASP development experiences. In fact, one of the first major ASP.NET applications made available to developers promoting best practices was the iBuySpy Portal and Store. These examples were delivered in code-behind form for VB.NET and C# developers and also in single-page ASP.NET implementations. Many developers to whom I speak about their preference for single-file ASP.NET applications point to the iBuySpy release as a justification for continued use of inline coding.

What’s the big deal?
A few issues are sure to come up in every .NET development shop doing ASP.NET development: Do we use C# or VB.NET as our core development language? Do we standardize on inline ASP.NET development, or do we rigidly enforce the use of code-behind files? The first question is best answered based on the experience of existing developers because it minimizes your training and adoption costs to use a language with which you’re already familiar. However, the code-behind debate isn’t as clear-cut. Although there are several references that insist codebehind is the right way to develop ASP.NET applications, I’ve never seen a published recommendation or preference from Microsoft. So how do you decide?

The architecture argument
From an architecture perspective, code-behind files allow for a cleaner system implementation. Code-behind files allow a developer to separate the UI display from the UI processing. The only code that should exist in the ASPX file itself is code (typically script) that specifically services the display. It’s easier (although still not simple) to reuse code in a code-behind file than in a single file with inline code. It’s also possible to separate the design and development functions by allowing designers to work on the ASPX file and coders to do the code-behind development. This is much more difficult to accomplish with inline code.

The environment argument
Although VS.NET allows you to create applications using inline code, its model of abstracting lower layers of UI processing using the code-behind files is much more intuitive. The compilers also do type checking and allow full IntelliSense when using code-behind files but not when you’re writing inline code. It’s possible to compile applications with errors in the inline code that appear only when the final code is executed. The same error-containing code placed in a code-behind file will be trapped when you compile the application.

Are there proper uses for inline code?
Having given the two main arguments for using code-behind files, I think it’s fair to point out that there are also two times that you may want to use inline code.

• You can change inline source code on the fly, and the change will be reflected the next time the page is accessed without having to recompile and redeploy. This harkens back to the old days of ASP programming and has certain advantages, but it flies in the face of any kind of formal change management process.
• If you’re writing code specific to the rendering of the display, performance and reusability are enhanced by putting that code inline. Some examples include code for DataGrid binding and Jscript code that displays rendering.

The bottom line
I advise my clients to use codebehind for one simple reason: You should strive to separate UI layout from UI or business logic. Those who use codebehind benefit from the advantages of compile-time warnings, type safety, and better debugging support because VS.NET was designed for code-behind development. Die-hard ASP developers who prefer inline coding will also bring back many of the disadvantages of ASP.

As architects, we understand that not all coding standard decisions are simple choices, but standards allow current and future developers to more easily understand, maintain, debug, and extend the code base we write today. Make sure your organization resolves the inline vs. code-behind debate before you get too far down the path of ASP.NET development.