The ASP.NET Dev Center on MSDN has started a Community Inbox where you can send in your questions to be answered by community leaders, such as Steve Smith, Andrew Duthie, Dino Esposito, and others. The most recently discussed question was: Should I use Code-Behind or Code-Inside? Code-Behind is the technique VS.NET forces you into when creating an ASP.NET Web application, whereas Code-Inside is the technique of using a server-side script block (<script runat=”server”>...</script>) in the HTML portion of the ASP.NET Web page.
Steve and Andrew chime in saying that Code-Behind is the way to go if you are using VS.NET, as it's the model the tool supports. Scott Hanselman essentially suggests to do what you want, as Visual Studio .NET 2005 will offer native support for either model. Dino has a dissenting opinion, stating that he's against Code-Behind. His main complaint is as follows:
What I dislike of VS.NET code-behind is that is requires an extra, mandatory compilation step and that forces you to deploy an assembly. I agree that this may be a negligible issue in the context of an enterprise project, however. All in all, I feel bad when I see that a keyword found in each @Page directive of a page created with VS.NET means little to the runtime expected to process that page. The keyword in question is CodeBehind. It's there only for the VS.NET editing purposes and ASP.NET gently skips over it. Try removing it and you'll see that the page is correctly processed but you'll have a hard time trying to re-edit it through VS.NET. The problem with code-behind is not with the technique itself--which is great and from a certain perspective even due--the point is the VS.NET implementation of it.
I think Dino is scratching at the surface of why Code-Behind in non-ideal, but he's a bit off the mark. It's not that Code-Behind is a good model, and there is just not sufficient tool support; rather, Code-Behind is a poor model chosen specifically because of the limitations of the tool (VS.NET 2002/2003).
I used to think Code-Behind was a decent programming paradigm. Sure, it had some weaknesses, but it was the required approach for building Web applications in VS.NET. It allowed for IntelliSense, debugging, etc. These views were shaken up a bit after talking to Andy Smith at the MVP Summit last week. Andy has just added a good entry on his blog titled Spaghetti, CodeInPage, CodeBehind, and CodeBeside, which articulates the points he made to me in Redmond. A definite must read. In addition to these shortcomings of Code-Behind, Andy also informed me that you could debug an ASP.NET Web page using the Code-Inside technique with VS.NET 2002/2003... granted, there's no IntelliSense, but debugging is possible.
Fortunately, this whole debate - and all associated confusion - over Code-Behind technique, is moot, as Visual Studio .NET 2005 will remove the need for Code-Behind as the editor will have IntelliSense in the HTML designer. Also, Code-Beside offers a panacea for the ills introduced by Code-Behind. As Andy points out in his blog entry, Code-Behind was a hack introduced to allow for ASP.NET Web page development in VS.NET 2002/2003. Thanks to needed upgrades in VS.NET 2005, the need for Code-Behind should vanish.