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 true.
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 the logical code behavior for that interface. And in some cases, the decision was made to encapsulate the generation of the UI along with the business logic all 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 perspective.
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 the logical code behavior for that interface. And in some cases, the decision was made to encapsulate the generation of the UI along with the business logic all 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 perspective.
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 came out, 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 the business 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 running and 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 your choice, 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 codebehind files - 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.
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 running and 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 your choice, 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 codebehind files - 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, repeaters, dropdown listboxes 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, the Visual Studio.NET IDE productivity gains in using the codebehind model cannot be disputed. What I mean very simply is, you 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 and properties in the IDE with codebehind 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.
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.
No comments:
Post a Comment