Discussion on:

The great ASP.NET code-behind debate

What .NET development standards have your development teams had the most difficulty agreeing upon?

I think inline code is fine for people making the transition to ASP.NET. But you should use the code-behind files as soon as possible. It is one of the best features of ASP.NET IMO. Why start using ASP.NET if you don't take advantage of the best features?

Web Matrix is a fantastic tool, especially for being free. But I hate that it encourages in-line coding practices.

I received this in an e-mail and thought it would be a good addition to this thread:

Why is this a debate? Anyone with any object-oriented training, particularly in the use of Design Patterns, will tell you right away that ?Code Behind? is the only approach one should consider for ASP.NET. Proper OO design means separation of concerns ? and that means separating application logic from user interface wherever possible.

This is especially important if your application needs to support many UI flavors: a Web page, a C++ client, a wireless cell phone, Palm Pilot, Windows CE, X-Box, an F-15, some goofy box the cable company has put into millions of homes, or a SOAP call from anything.

Benefits of Inline:

Stuff in one place
Allows change on the fly

Drawbacks:

Spaghetti Code
Un-reusable code and (worse) un-reusable design
Web page designers are not coders and cannot maintain the mixed pages

Code Behind Benefits:

Allows designers to build & maintain pretty web pages without seeing a bunch of code
Allows coders to focus on code
Promotes reusable application design and code

Drawbacks

Changes require recompiles

Java did the same thing when they came out with JSP. They quickly found that mixing Java scriptlets (the code in between <% <>) with HTML produced pages that only programmers could maintain and logic that could not be readily reused. They soon introduced Tag Libraries and Jakarta Struts to get the code out of the pages. ASP.NET and code behinds do the same thing.

IMHO, the difference between ?inline? and ?code behind? is the difference between hacking software and software engineering.

I am great proponent of d&d programming. However, my team doesn't agree (I'm the manager). I came to this job from client/server programming (albeit a couple of years ago) and I'm wary of dictating to them on this subject. I'm trying to convince them of the efficiencies of using the d&d capabilities in VS7, but they love their text editors. This code behind issue may be the way I break their notepad habit

I would love to hear what others have to say about using the drag and drop programming capabilities of VS7. If they weren't supposed to be used, why were they built?

Here's a good article on MSDN on the App architecture that was written a couple of months ago.

http://msdn.microsoft.com/architecture/default.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/AppArchCh2.asp?frame=true&hidetoc=true

In the article, I would disagree w/ the IBUYSPY being an example of good programming practices. The coding practices used are pretty horrible in those samples, and they were mainly given to showcase what the technology could do.The Petshop examples are at least closer to proper coding techniques.

Nice article, Tim.

I find myself firmly in the code-behind camp on this debate. Sprinkling script in amongst HTML always made me feel dirty somehow...

I'm particularly distressed that of the 8 or so ASP.NET books I've looked at so far, all of them start out with inline code and use it throughout the book. A few books never really make any use of code-behind at all.

Remember also that Code-behind allows direct debugging. Further, when compiling, if there is a syntatical or logical error, the assembly won't compile and you're site continues functioning with the original behavior. Once compiled, that assembly canbe referenced by other web sites or even applications which can leverate it's code in a truely object-oriented fashion., that can again be debugged across several assemblies, sites, domains, etc. In fact, the only argument I can see for inline code at this point is to allow a transition period while the forms are being re-written for code-behind. I certainly would NOT recommend to anyone that inline provides in any way any sort of advantage over code-behind.

You failed to mention the only two valid reasons to use codebehind:

1: You can write and sell a web based application without giving the code away.

The aspx.cs files and the .cs files are compiled, and need not be shipped with the web. So, allyour code is supposedly protected, and the users have to come to you for updates. This has been the model for the last few years, using cgi's and or .ocx's / .dll's to hold your propriatary code. But now, with .net, it (supposedly) happens instantlywithout having to shift into C++ or VB for half your project.

2: The "comterpreted" code (msil) loads and runs much more quickly in IIS than the same functionality all shoved into scripts. If you have ever written a compiler (required when I wasin school) or an interpreter (I've written many) you know about the many passes you make through a source file before it becomes machine language. MSIL has already been cleaned, syntax checked, and tokenized such that the interpreter only needs to load it and start executing. We also get a protected garbage collected environment that will (theoretically) stop memory leaks. Imagine an IIS machine staying up without reboots for years like Linux machines currently do. I'm sure Microsoft dreams of a machine that can stay up for more than a few months without a reboot.

I believe anyone who misses these points (like the author) should NOT be working in the computer software business. Everyone knows about the shift to browser based applications. The MOST critical factor in being able to sell a web, is protecting your code so the users can't copy paste modify and sell your work behind your back.

It seems that jdieter@twonails.com is slightly disgruntled, wouldn't you say?
As for point #1:
Give me your "Out-Of-The-Box" Web application DLL's that you seem to feel are so safe and I'll have the source code disassembled and back to you in about 5 minutes. There is no such thing as a safe .NET assembly, everyone knows that. Point #1 is null.
Point #2:
Everyone knows that ASPX files are precompiled and stay that way until a new version is recognized by IIS, this is the exact same behavioras JSP files. IIS doesn't have to compile at run-time the MSIL required to execute the ASPX, you need to do some research as this is basic ASP.NET functionality. Point 2 is null and void of merit, so your entire response is basically misinformed andinaccurate.
Not everybody on the planet is building a sellable Web application and to make an ignorant ridiculous statement that they shouldn't be in the computer business because they happened to
write an article that isn't "exactly" what you do for your own business befuddles me.

The author's points are perfectly valid, and in my view this is a good article.

The author's ommission of your favourite code behind arguments does not automatically make him wrong. If you are going to put posts up claiming things like that, you have to do more to justify your stance. All you have succeeded in doing is making yourself look foolish.

Near the end of the article, he says to use codebehind:
"...I advise my clients to use codebehind for one simple reason..."

I've met very few (computer science degree level) software engineers who had more than a very basic idea about what compilers did, and more importantly, how they did it. This basic idea was usually derived from their attending a few lectures covering the topic in rather sketchy detail, and to which they didn't pay much serious attention because the topic didn't seem to be about "real" computing.

One of the reasons for this is, of course, that the underlying theory for compilers tends to involve a lot of mathematics (particularly the group theory required for lexical or syntactical analysis) that most software engineers can't see any further use for except if they are going to concentrate on writing compilers, assemblers or interpreters.

I am fairly certain that courses of this nature never get close to requiring their attenders to actually "write" compilers. Such a level of involvement would normally happen towards the end of a post-graduate research course.

[A long-sufferingAlgol 68 compiler writer.]

University Of the Pacific, at least when I was there, had a class called Compiler Construction. This class requires that the students write a compiler. I took this class as an undergraduate, not a post-graduate research course.
This was a particularly nasty course for undergraduates, but I still use the priciples that I learned to write communication software.

re: Give me your ... and I'll have the source code disassembled in five minutes ... There is no such thing as a safe .NET assembly
First, you don't disassemble source code, it's the other way around. And yeah, you can reverse engineer machine language, but it ain't that easy to work with. I posted a zip file with a .net web application in it to ftp://www.twonails.com logon as adnan and use the password anonymous. There is a key in the function EncryptTrippleDES. post back the source code to hereyougo.dll - or just the key.
The clock is running: 20030218 11:51am

RE: .aspx files are precompiled... I guess you got me. So, exactly how is all that javascript you have to write in inline code converted into msil?

This took me about 30 seconds to acquire. For security reasons I will not post my methods. Here is the code:

public string EncryptTripleDES(string Plaintext) {
byte[] local0;
TripleDESCryptoServiceProvider local1;
MD5CryptoServiceProvider local2;
ICryptoTransform local3;
byte[] local4;

RuntimeHelpers.InitializeArray(new Byte[8], );
local0 = new Byte[8];
local1 = new TripleDESCryptoServiceProvider();
local2 = new MD5CryptoServiceProvider();
local1.Key = local2.ComputeHash(local0);
local1.Mode = 2;
local3 = local1.CreateEncryptor();
local4 = Encoding.ASCII.GetBytes(Plaintext);
return Convert.ToBase64String(local3.TransformFinalBlock(local4, 0, (int) local4.Length));
}

It's not exact but that's how the functions break down into MSIL and then back up into C#.

How close am I?

Cool, but as I suspected, not useful. You don't have the key, and it dosen't even compile. Could you imagine trying to work with an entire project that's been "uncompiled". Maybe an illustration will make my point better. A client came to me and said he wanted me to break the copy protection for a particular application. I told him, it would be easier just to write an identical app from scratch.

This is probably an extension of the architecture justification, but a key rationale for code behind is simplifying maintenance.

I have used Microsoft BAT files, UNIX shell scripts, and ASP scripts; and all exhibit the tendency to put too much complexity into one file. It is debatable whether it takes longer to initially create a multi-file, object based design than to create a single script, it is almost always much easier for someone else to modify the code if it is logically decomposed into bite size chunks.

If the result is a one time page that will never be updated or changed, the architecture question is moot. If, however, follow on programmers will need to maintain the code, architecture becomes a key criteria.

Here is a question our team has debated without much success and I would like to hear others' opinions. Should HTML generation code be part of the business logic code?

The purist argument is that all HTML generation should be done at the ASP level and the underlying business logic should not create HTML. The business logic should not provide any code specific to Web, Web Services, or Client?server user interfaces.

The other argument is that it is easier to debug and maintain code written in something other than ASP. Although HTML generators could be written in ASP, why not write them in VB and merely pass up the resulting string?

We are currently leaving the decision up to individual discretion, but I am curious if others have had similiar discussions and what their decisions were.

Why would you not return XML and transform it into HTML using XSL and CSS? That solves all
such problems right away.

At last someone mentioned about XML/XSLT. I use the same approach for presentation layer.
I have a COM object coming from old times of ASP, which handles business logic. I query it in my code behind and tranform coming XML with XSLT to show as XHTML for my user

Gokhan Arli
www.sylow.net

It seems to me that ASP.NET follows the MVC architecture pattern:

Model - Components in component tray
View - Controls on designer surface
Controller - code-behind, which contains and/or accesses business logic