Over the last 2 years, I’ve run into several situations
where developers have moved from classic ASP to ASP.NET and have chosen
(not always correctly, in my opinion) to use their own "custom methodology"
in an effort to avoid the codebehind
model that’s built into Visual Studio.NET. There are a number of reasons
for this; they're not always all logical, and some are downright fallacious.
I'll try to address some here and hopefully some of these ideas will ring
Lots of us web programmers learned to write Active Server Pages
using Visual Interdev or similar web-development tools. Many of us have
had a difficult time adjusting to the VS.NET paradigm. I know I certainly
did. Developers coming from
Classic ASP are used to breaking down their applications into a series
of ASP pages, each encapsulating both the visual HTML interface and
code behavior for that interface. And in some cases, the decision was
made to encapsulate the generation of the UI along with the business
in the same code methods with inline looping and construction of UI elements
with multiple Response.Writes – not usually a good OOP programming
decision, because the UI portion has now gotten irretrievably bound to
the business logic behind
it. Of course in Classic ASP, we often didn't have any other choice except
perhaps for filling in <%=xyz %> script tags that were interspersed
with our HTML elements. However, when this technique is now translated
into ASP.NET where major elements of the resultant UI are now locked
up hardcoded into class libraries, it becomes even more ugly from a maintenance
If you look at many of the code samples from the
.NET beta days that were written mostly by ASP developers using the Framework
SDK, before VS.NET
you'll see lots of inline code examples. Even the first IBuySpy reference
app was delivered in both code-behind form and in single-page
code - inline ASP.NET pages. I remember - I was there at PDC 2000 when
they gave it out!
The term “Codebehind” simply refers to code
that a web form (or web service or user control or other ASP.NET page type)
uses that is not located
in the ASPX or other file requested by the browser. The design /
architecture process of separating code from the primarily HTML within
a web form offers
many advantages, not the least of which are allowing GUI and graphics
designers to work with the HTML in say, Dreamweaver without destroying
logic, and especially for VS.NET users, greatly enhanced support
from the IDE. Visual Studio .NET has almost no support for coding within
an ASPX page
using <script runat="server> inline code. Consequently, developers
who have chosen to use this as their primary programming model have - by
definition - forced themselves into a very restricted programming model
from an IDE productivity standpoint.
Even an ASPX page with no code on it gets turned into an instance
of the System.Web.UI.Page class. The page is parsed by the ASP.NET
engine when it
is first requested, and then its JIT compiled version is cached
in the Temporary ASP.NET Files folder as long as the application is
the .aspx page
hasn't been changed. Since the ASPX page is always instantiated
as an object, you can modify its parent class and have it inherit from
a class of
provided that your class eventually inherits from System.Web.UI.Page. You
can also have different pages set references to the class files of other
pages, which makes possible some very interesting sharing of items.
Visual Studio .NET uses the Codebehind attribute by default. The
Codebehind attribute is completely ignored by the ASP.NET runtime.
It is only
used at design time by Visual Studio .NET to associate files
with their codebehind
class files during development. Since VS.NET projects compile
all files in
the same project into a single assembly that is placed in the
/bin folder, there is no need for any runtime JIT compilation of the
- the assemblies are all found in the /bin folder. This makes
for efficiency of
code execution because the code for multiple pages, Global and
other classes are all in a single assembly in memory, and also can help
prevent problems by not having lots of strangely - named JIT – compiled
assemblies in the Temporary ASP.NET Files directory.
Probably the single biggest advantage of using the Codebehind
paradigm, in my opinion, is the ability to wire up intrinsic and custom
events, using ASP.NET intrinsic and custom servercontrols such as DataGrids,
and many others, and provide a much richer, more professional "Windows
- like" experience for the user. While this can be done with inline code,
its not easy, and it certainly is not fun. Combined with ViewState, Cache,
Session, SmartNavigation and other built-in technologies,
IDE productivity gains in using the codebehind model cannot be disputed.
What I mean very simply is,
would have to write one hell of a lot of custom code to get most of the
functionality of the ASP.NET DataGrid control, but why on earth would you
want to do it when 90% of the time you can get everything you need and
more from the built - in control ( or you can derive from it and customize
even more)? If you have made the investment of time required to study it,
it's possible to set more DataGrid custom UI behavior, DataBinding, attributes
in the IDE with
in ten minutes
just by using the Properties TAB than many developers could write in a day, using
inline - only coding techniques.
Page design is also enhanced because you can choose between Grid and Flow layout
and precisely position page elements in the Designer.
Although VS.NET doesn't stop you from creating
applications using inline code, its model of abstracting lower layers of
UI processing using the code-behind
paradigm is much more intuitive. The compiler can also do type
checking and allow full IntelliSense when using code-behind files; these
are not readily available when you’re
writing inline code. It’s possible to compile applications
that have errors in the inline code which become apparent only
when the final code is
executed. The same error-containing code placed in a code-behind
file will be trapped when you attempt to do a build. This makes
for a much more productive, RAD experience, especially when
multiple developers are simultaneously working on the same
codebase in a source - control environment.
Is there an Inline Code Justification?
Sure there is. There are certain situations where a purely inline
- code implementation is justified. However, in many of these cases, upon
inspection, it can be determined that the developers who claim they "had
to do it this way" could have, with a little study, implemented it
with the codebehind paradigm after all, had they taken the time to solve
the minor complexities
that seemed to at first compel them to use an inline-only code implementation.
The benefits to the developer group and its potential new members
in terms of ease of maintenance and developer productivity will almost always
be worth the small amount of pain that must be endured to make it happen.
probably hear lots of objections from developers who want to avoid using the
Codebehind model. My experience has
been that most of these objections are born more out of lack of knowledge
and experience than from careful thought and study. Do you agree? Disagree?
to post your comments in our forums in the Article
As architects, we understand that not all coding standard decisions
are easy choices, but having standards in an organization
allows current and future developers to
more easily understand, maintain, debug, and extend the codebase
they work on daily. Make sure your company successfully resolves the
inline vs. code-behind debate before you get too far down the development
After all, you don't want to wake up one morning with a new career where your
vocabulary consists of the sole phrase "Paper or plastic?".
|Peter Bromberg is a C# MVP, MCP, and .NET consultant who has worked in the banking and financial industry for 20 years. He has architected and developed web - based corporate distributed application solutions since 1995, and focuses exclusively on the .NET Platform. |