ASP.NET certainly doesn’t encourage spaghetti code. It is rigorously object-based and builds atop a family of easily extensible server-side controls. The structure of an ASP.NET page is extremely modular, with three distinct sections—page directives, code, and page layout.
Page directives Page directives set up the environment in which the page will run, specify how the HTTP run time should process the page, and determine which assumptions about the page are safe to make. Directives also let you import namespaces to simplify coding, load assemblies not currently in the Global Assembly Cache (GAC), and register new controls with custom tag names and namespace prefixes.
Code section The code section, with the misleading tag name of <script>, includes any source code that is pertinent to the page. You typically place event handlers and helper routines in this code section, which by itself can be extremely long. It can even grow pretty long in toy projects that do little more than say hello to the world.
Page layout The page layout represents the skeleton of the page, which you flesh out a bit with code.
As you can see, the structure of an ASP.NET page resembles lasagne rather than spaghetti. You have three noodles with rich sauce and various meats and <script> cheeses in the middle. While extremely tasty, however, lasagnes are not ideal for healthy eating. They are pretty dense in calories and end up leaving a significant memory footprint in your digestive run time system.
If you’ve ever served a good dish of lasagna, you know that the taste lies not in the number of noodles but in what you find between them. The directive noodle is relatively lightweight, as is the layout noodle. Both noodles are necessary for holding the ASP.NET lasagne together.
The code noodle is what determines, for the most part, the nutrition and the calories of the dish you are serving. A very lengthy code section can make your ASP.NET page very hard to manage, nonmodular, and prone to code duplication across the pages of the project. This trend grows linearly with the size of the project, and it soon reaches the critical threshold that triggers unexpected reactions. Keeping the code noodle as thin as possible is vital to the health of your application.
The layout noodles, too, can be kept somewhat thin. My recommendations here are not so much to enhance raw performance, as any ASP.NET tag maps to a run-time control that relies on compiled and managed code. Rather, my focus is more on design. Slim, modular, even stateless programmable components are much easier to manage. More components means task pooling between the members of the team. And separation between noodles means that each single cook can prepare his or her preferred sauce using the finest ingredients.
There are basically two ways to make the ASP.NET lasagna pages more easily digestible: you can take the whole code section out of the ASP.NET page, and you can try to simplify the page layout by grouping individual controls in a new, single, wrapped-up composite control, which you would embed in the page as a user control. Smarter and more effective ASP.NET pages rely heavily on pieces of extensible and reusable code. In ASP.NET, the demand for reusable code finds three possible answers: the code-behind approach, user controls, and custom Web controls.