Code inline or Code behind ?

Well this post is just my opinion, and I am sure this will not change Microsoft view on the subject.

I have some concerns on the choice made in ASP.Net 2.0 to set the code inline by default. I am ok with the new partial class feature, and I found this is a great idea.

But mixing the code and the HTML ring a bell in my mind about the old ASP time. Remember spaghetti code ?

So why this has to be the default ? You can expect that beginners (or lazy coders :-)) will jump on this new approach. I read this make the things easy to maintain with only one file, but are we sure it is so important ?

Just an example. Currently if a designer want to modify the ASPX page (with my authorisation of course), I don't have to worry too much about my code which is perfectly safe in its DLL.

Tomorrow if I use the 'by default' in Visual Studio, I  will be to scare that by accident someone change anything in my code. Indeed I can use master pages and templates, but if I don't want ?

It's also true that with code behind, I can change some of my code, compile a new DLL and deploy. No need to touch my webpages.

I can see this move as an attempt to seduce web developers scared by real code. Well if it's the case, this is really wrong. Nothing much cleaner than a good separation between code and presentation.

As I wrote at the start, no way I can change Microsoft's mind. But between the two camp, I know already where I stand up.

 

9 Comments

  • I agree with you. The code-behind approach also improved productivity (at some level) since the designer and the developer can continue working simultaneously on the same set of application. Its also easier to build & test the UI and the business logic (DLL) - separately or combined. Inline coding is a horrific experience unless you have an efficient template engine in place (which takes care of the presentation tier). This might ease it till some extent, IMO.

  • Yes and the problem now is that most of the future published articles will go on the inline way, showing bad practices, because it's design like this by default.

    I still can see a lot of books using embedded server script code in the HTML pages. Yes it's surely more economic but it's not showing beginners the right way.

  • The default in both Visual Studio and Visual Web Developer Beta1 is actually to use code-behind with ASP.NET 2.0. Code-inline is not the default and not recommended for complex projects.



    Note that with Beta2 we will also have the ability as part of the build/deploy step to pre-compile the code-behind classes into a DLL but keep the html source and master pages un-compiled for designers to still work on (without giving them any access to the code). This enables similar workflows as what is available with code-behind today. The benefit, though, is that it still uses partial classes -- which makes the code a lot cleaner.



    Hope this helps,



    Scott

  • Schwew!



    I was really scared there for a minute -- experiencing waking visions of my nightmares about the days of in-line coding.

  • I'm voting for code behind as well. I like the partial class idea, so we no longer have to declare all the controls in the code (just worked on a HUGE job application recently with 50+ fields -_-)...



    Code inline's good for small scripting, experimental pages... MS wants newbies to use .NET as well... That's why they've got the web developer express... But making code inline a default? Oh no... I don't wanna check that box every time...

  • I'm voting for code behind as well. I like the partial class idea, so we no longer have to declare all the controls in the code (just worked on a HUGE job application recently with 50+ fields -_-)...



    Code inline's good for small scripting, experimental pages... MS wants newbies to use .NET as well... That's why they've got the web developer express... But making code inline a default? Oh no... I don't wanna check that box every time...

  • Scott thanks to clarify but the article on MSDN clearly mention code inline as the default.

    So where is the truth ?

  • I'm going to have to disagree here. There is no separation of concerns between ASPX control meta-markup / (X)HTML and the sort of code that should be in either inline or code-behind. The coupling is too tight to justify managing two separate files just because one contains declarative markup and the other contains procedural instructions.



    Nothing will stop an inexperienced developer from putting BL/DA code in the UI tier, but a code-behind is as much in the UI tier as the aspx file, and code that is wrong is one is just as wrong in the other. And if your HTML contains complex enough markup that it requires separating code for sanity, you're probably not making effective use of CSS and server-side controls.



    Frankly, I think we need *more* IDE capabilities to mix and match various languages in the same file. Why must RegEx expressions be escaped into unvalidated strings? Why must authors writing XML code resort to silly calls to methods such as "AddNode()" rather than just writing the XML like inline HTML in an ASPX file?



    None of this affects me, however, since I don't use VS.NET for web applications... a good text editor gives me much better control over the layer that many ASP.NET developers ignore: the actual produced XHTML and CSS.

  • I don't think anyone says "separation" meaning "tiers". Separation is needed so that a designer I am working with can open an aspx file in dreamweaver or notepad, make some changes, and push the changes without destroying my code or having to dodge it. Even in "ASP Classic", I work in a similar fashion, moving as much code as I can into classes that are included into the ASP file.

    Neither I nor my designers want to see a single line of C# mixed in with the ASPX code. The separation in the Code-behind model is real and real useful.

Comments have been disabled for this content.