asp.net - Web Site vs. Web Application
For more info, see my follow-up article: ASP.NET: web site vs. web application project - Part 2
A few years ago, when I first got a look at asp.net 2.0, it was clear to me that there must have been some serious changes inside the development team at Microsoft. ASP.NET 1.x was a huge leap forward in server side web application frameworks, but it was also geared to an object oriented audience. While it did support direct data access from web pages and everything-in-one-file styles, Visual Studio's use of asp.net encouraged a more tiered design with clean separation of presentation, business, and data access. It also encouraged OO design by making inheritance, namespaces, and assemblies all obvious, simple, and the default way of things.
By the time asp.net 2.0 was coming out, more agile languages were getting all the buzz. PHP was still relevant and Ruby on Rails was shaping up to be the next big contender. By that time Java's JSP, the only other heavy OO platform that still mattered, had fallen flat on its face. So it wasn't exactly a surprise that there was a focus within asp.net 2.0 towards the "less is more" philosophy of quick, dirty, do-what-I-mean design. Codeless databinding, master pages, skins, themes, and configuration driven providers for common stuff like membership, profiles, personalization, etc. were all expected.
But what make several of us step back was the new compilation model and the "project-less" web site... er... project. Aside from being one of the most impossible to name mechanisms, it was also a breaking change in how asp.net was done. The new compilation model threw out the visual studio project file itself, took asp.net back to the "compile-on-the-fly" concept, all but eliminated the use of namespaces within a web site, and radically altered the way UI template and the associated code-behind were arranged.
But for those of us doing serious web frameworks in large or complex environments, the web site model had some serious drawbacks. The biggest for me was having to manually deal with namespaces, which the UI and code designers would fight every step of the way (until you finally gave up and just let it pile up in one big default namespace). The loss of the visual studio project files was also painful, and it lead to an awkward "exclude from project" mechanism where the only way to get Visual Studio to ignore a file was to physically rename it. Large web sites with lots of code suffered horribly in performance because so many helpful visual studio features, like refactoring and the verification compiler had to sift through every file in the project with no guidance from project configuration.
Microsoft seemed to notice the problem, and resurrected the old project model in what they called the "Web Application" Project. This was essentially a retro-fitted clone of the old project model complete with designer generated code files (updated to take advantage of partial classes though). The new project type brought back namespaces, and once again encouraged clean OO design patterns. It also became apparent over a very short time that Microsoft itself would consider the web application model the new "enterprise" project type while the web site project type was more for the beginner and casual developers. For example, Team system's testing, build, and deployment work great with the web application project, but work poorly if at all with web site projects. But the new project type also brought with it the need to compile everything in advance, and used a different mechanism to associate UI and code-behind files that was incompatible with dynamic compilation.
With Visual Studio 2008 Microsoft is keeping both project types. But I think they are missing an opportunity. While the web application project and web site projects both have advantages and disadvantages, there doesn't seem to be a compelling reason for some of the features to be mutually exclusive.
I for one would love to see a hybrid project type. Keep the project file to organize the site and give us a place to put visual studio specific settings. But switch it use the dynamic compilation model from web site projects. Dynamic compilation and xcopy deployment were powerful ideas, and I can't see any reason they can't be used still. The verification compiler can be optimized quite a lot by having access to a project file... exclusions can be dealt with elegantly, and the whole thing can be sped up. For other code though, you could choose to continue to compile to an assembly in advance, or leverage the app_code folder for dynamic compilation, or a combination of both. And of course, keep the namespaces and configurable compiler options.
I'd love to see a web project type that keeps the best of web site and web application projects both. Give me control over the project's structure, namespaces, and compilation but also give me xcopy deployment, dynamic compilation (using my settings), and keep a consistent way of associating an asp.net UI file to its code-behind without requiring the designer generated code file and full compilation.
Oh well, maybe in the next release.
Thursday, November 01 2007
Filed under: Code
Tagged as: aspnet, web, visual-studio
13 Comments
