ASP.NET 2.0 takes away from the code-behind model

Much has been said about ASP.NET code-beside vs. code-behind when the PDC preview of Whidbey (err, VS2005) rolled out. At the time, if memory serves, the IDE added support for code-beside and seemed to deprecate the code-behind model. The outcry from developers missing code-beside centered around the ability to check code for compile errors prior to deploying the application.

The VS.Net team listened and, as of the May 2004 CTP release, brought back the ability to run a "compile" check against a web application. I put the word "compile" in quotes because no output assembly is actually generated, and therein lies one of the problems.

The deployment story of ASP.NET applications has taken a small step forward and a large step back. While it is now possible to precompile and deploy the entire web application (code and markup), it no longer appears possible to have the IDE compile just a code assembly while leaving the markup files intact and editable. The former solves the IP problem for those cases when one wants to protect the application from tampering; the latter allowed for true separation of code from layout markup. The developer used to be able to compile and deploy the application, and at a later time it was possible to make markup (or verbiage) tweaks and fixes without going back to code. It also enabled certain skinning scenarios like one I architected at work. It is beyond me why the VS.NET team chose to remove this feature from Whidbey.

Another big problem I see with ASP.NET development in Whidbey is the dumbing down of the web page code editing model. In VS.NET 2002 and 2003, one could employ a fully OO model to develop web sites. In 2005 timeframe, it looks like we are being given partial classes and editor magic and having the true power of the framework taken away from us. This is the proverbial "dumb VB approach" and again, I just don't get it. Yes, its great to be able to have a partial class with just my code and none of the declarative UI crud. But why take away the ability to build page object hierarchies? Why discourage the use of namespaces?? I may buy the argument that this direction is appropriate for the Express line of products, but the Architect edition should be geared towards enhancing the productivity of developers who build LARGE, COMPLEX applications, not dumbing down their world to make building their personal web site simpler.

Note: I realize that the framework still allows for these scenarios. It is the IDE I have the problem with, which used to enble them and no longer does.

posted @ Monday, July 5, 2004 9:49 AM


Comments on this entry:

# re: ASP.NET 2.0 takes away from the code-behind model

Left by Sankar.B at 7/6/2004 8:22 PM

Yes ur right. The Initialise part and the webform designer generated code can be given in a seperate partial class as WebForm1.Designer.aspx.cs as given in the partial class WinForm1.Designer.cs which has all the VS.NET IDE designer generated code. And the EntryPoint.cs has a clear seperation of starting up the WinForm (Offcourse WebForm does'nt require an entrypoint.cs). So, itll be better a Designer.aspx.cs file for the WebForm's also.

And, as stated above, it is def. required that we need the functionality to build only the .cs files and deploy the ASPX, ASCS files as it is during deployment.

Also, again, as stated above, the need for including the namespaces in the cs file is required. Now, i feel im not working in a fully featured IDE. It looks like im working in FrontPage where everything is wrapped. We will forget what namespace to be included for at some point of time if we continue working in ASP.NET 2.0. One thing can be done. If i declare DataSet in my aspx.cs file, the IDE can include the Namespace System.Data in the using region automatically. If required, we can go and see if its included.

With Regards,

# re: ASP.NET 2.0 takes away from the code-behind model

Left by Willie T. at 8/13/2004 10:33 AM
Also, the data controls are great, but the inline sql commands are a bit strange. What ever happend to code seperation with business and data access layers? I'm just beginning to play around with this, but I'm sure hoping that I can just have a sealed (static too now) class that will allow me to bind data easily.

One more thing, the master pages aren't what I thought they were going to be. I think I'll take my own BasePage class any day. What's with the DIV tag when you generate a new page. header runat=server??


# re: ASP.NET 2.0 takes away from the code-behind model

Left by Michael Giagnocavo at 10/12/2004 5:52 AM
YES! I agree with you exactly. I'm extremely annoyed with the new IDE crap in this area. I want a full DLL compiled and I want to be able to reference other code without using a bloody Code directory (what kinda crap is that?). The current model breaks a lot of things I do, and makes me re-org my code layout to fit under the Code directory, and that massively sucks.

Perhaps we can get it working via a post-build or pre-build event if MS refuses to uncripple the product...?
Comments have been closed on this topic.