Codebehind vs. Codeinline: war is over

Note: this entry has moved.

Monday at the PDC03 has been an extremely busy day and today looks even busier. I managed to get some free time this morning (missed breakfast) so here goes my first PDC03-post:

What is your personal preference? Are you a codebehind fan or a code inline one?

On how many “codebehind vs. code-inline wars” have you ever been involved?

This would be the usual stuff coming from guy #1, a codebehind-lover:

“…I don’t like mixing UI with code, period; who in the world may want to mix presentation markup with code? This is such a bad idea that even VS.NET offers zero support for it. Ever tried to edit some code embedded into an .aspx? No intellisense, no coloring, no nothing. Moreover, it’s a nightmare, you’ve to deploy your sources along with your application…”

Now, some stuff coming from guy #2, a codeinline-fan:

“…Well, I laugh at poor codebehind-lovers. They have to recompile their 3000-pages app if they decide to change a single .aspx, everything they touch causes an application-restart. Also the dependencies that exist between the parser-generated class and the codebehind class are ugly, plus, VS.NET will usually decide to wipe out your event handling and initialization code. Finally, they usually like to stick to the IP-protection argument, that’s only because they’re afraid to show their ugly code!...”

So what would be the ideal model that could make both of these two guys happy? Let’s see:

VS.NET support

The major pain while working with code embedded into an .aspx is the lack of VS.NET support for this. If VS.NET could clearly present you, as WebMatrix does today, with an html-view, code-view, etc, it won’t matter much if UI + code is finally stored in a single file or its separated in two. So, making VS.NET smart enough to support this, plus giving you the option to still separate them into two files (if that makes you feel any better) should satisfy everyone.

Dynamic compilation

No matter if you’re putting your code into the .aspx or in a separate file, you should always get the benefit of dynamic compilation, that’s is: compilation of the UI and code for your pages on the fly, without having to rebuild the entire application (and without the obvious application restart too).

IP protection

You should be given the option to deploy your code in a compiled form (no sources) even if you decide to write your code into the .aspx

Making OO purists happier

While today’s codebehind model works, it has some big compromises. The main one is the implied assumption that exists between the codebehind and the parser-generated classes; from an OO perspective this is really ugly (i.e., a base class expecting some specific behaviour of the super class).

Well... everything described in the above paragraphs is already offered by the Whidbey bits; how they did accomplished this?

One of the most notorious changes was made possible by the introduction of support for partial classes. This allows us to declare our (previously named) codebehind class like this:

The page parser will declare a class in exactly the same way as shown above. At compile time, both declarations will be merged and compiled as a single class thus eliminating the need for two separate classes (and the nasty assumptions made between them). Also, all the autogenerated  code (i.e. InitializedComponent method with all the event wireup code; yes, the method VS.NET likes to modify on its own from time to time) is now being found in the parser generated partial class (each generated __BuildControl* method now also contains the event wireup code for that particular control). 

But… wait a minute!! Now, if there is only a single class, that means that we could freely move our code around between code inline and codebehind (or Code Beside as it is being called by now) without any trouble. That’s possible. Don't be fooled by the fact that you can still choose to have two separate files. The war’s over.