Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

The ASP.NET code behind programming model

I sat here one day thinking: Why do all these people celebrate the web form/code behind programming model? The doctrine seems to be "separate the code from GUI and spaghetti code is gone".

But the web form programming model is not different from the VB6 form programming model we have had for years. And we know what people said about that (toy language, no objects (ha), not for large project, code is doomed to be bad).

I am these days working on my first web forms. I do my code behind in C#, so the result should be clean and streamlined, right? Wrong. If you don't understand the programming model, you have the basis for the ugliest code ever. I am still refactoring as the understanding slowly emerges.

But isn't it powerful? Oh, yes. If you understand the programming model. If not, you'll miss classic ASP.

Thomas Eyde
Thursday, September 19, 2002

Code-behind at least gives you the chance to get some separation of behavior from presentation, and the possibility of reuse of behavior (via inheritance) between separate pages.

In classic ASP you didn't even have the opportunity.

Nothing will prevent bad programmers from producing crap, but the old model got in the way of making good stuff too. At least with codebehind there's a chance.

All these arguments also apply to Java Servelets and JSP BTW.

Chris Tavares
Thursday, September 19, 2002

Um, you can do either the code behind or put your code in the ASPX page (like ASP).  I actually like the code-behind page model, although I'm not sure how it will scale.  The biggest problem I have in developing web pages is that there is no good integration between web designers (the people who use photoshop and dreamweaver) and web developers (people who take the HTML & graphics the web designers make and put it into an ASP/X page).  Everytime I get the HTML for a page, I have to rework it to get it to work in an ASP page.  It would be nice if a web designer could just edit the ASPX page and get it looking just right, check it in to CVS, and then I could hook up the logic.  Well, they like using dreamweaver and I think that the <asp:textbox></asp:textbox> tags would get in the way.

Tim
Thursday, September 19, 2002

There are people who will gravitate towards the code-behind model and there are those who prefer the in-line model.

VS.NET does the former and the ASP.NET Web Matrix IDE does the latter.

The beauty here is that you have a choice, and from a performance point of view, there is absolutely no difference between the two.

In the end, has not the difference always been the skill and elegance that you bring to the craft rather than the tools that you use?

Anil

Anil John
Thursday, September 19, 2002

I used to wonder what is the real different between classic asp includes and .NET code behind but as it was mentioned code behind feature comes with inheritance.

I think performance matters as it is no more scripting and code is compiled. Am i right?

RAM
Thursday, September 19, 2002

It isn't as much as "code-behind" versus "in line" -- its about linear versus event-driven.  Code behind is just a little extra file -- doesn't change much.

And events are exactly like the VB6 model.  Sure, you can get ugly code (with C#, VB, Component Pascal or COBOL, heck, it could get ugly even if you wrote it in IL), but that has nothing to do with anything here.  If you want something clean, then go make some objects -- build a three tier system.  With awesome SOAP support and beautiful .NET Remoting, this is easier than ever (well, apart from easily being able to make objects right inside the same web assembly).

ASP.NET *allows* you to have clean code.  With ASP3, that was nearly impossible (try having 1 form handle 5 different things).  But, like any technology, it can't *force* you to have clean code.  That's why good programmers can still charge more ;).

Michael Giagnocavo
Thursday, September 19, 2002

I've done 4 or so web projects with ASP.NET using code behind on all of them. There's definitely a learning curve and "programmers" that cut their teeth on ASP seem to be doomed. An understanding of OO is a requirement to really do ASP.NET right.

One thing I like about code-behind is that it lowers the number of files in a deployment. I can make changes in ten different places on a site and I only have to deploy a single .dll file.

Luke Duff
Thursday, September 19, 2002

I think Tim was 100% correct when he said that there wasn't an easy way to seperate the work from HTML developers and Programmers with the code-behind model. 

When I developed in ASP (and perl and servlets too), I would take the HTML given by an HTML guy, put it into a template file or variable, and then add a neat little <%=%> where I needed to print my dnamyic stuff.  It doesn't seem as easy with the code-behind model.  People complained that ASP was messy, but it didn't have to be. 

Vincent Marquez
Thursday, September 19, 2002

How about an explanation of what the code behind model is?

Is it:
An ASPX file is called, it does all the processing, db calls, assigns output to variables, then calls a static html file which contains placeholders that get parsed out with the variables from your ASPX file?

That allows a web des to design, and a web dev to code.

Is that what it is?

As you can tell, I'm not doing .net yet, still trying to find out why I should (probably should start a different thread on that topic)

steve wasiura
Thursday, September 19, 2002

What is code-behind?

An ASP.NET page can be divided into two files. One file which contains the presentation content and the other file, called the code-behind file, which contains all of the application logic.

The code behind page actually inherits from the Page class and the presentation file in turn inherits from the code-behind file so all of the properties, methods and events in of the Page class are available in the code-behind file and all of the properties, methods and events in the code-behind file are available to the presentation file.

Hope this helps..

Anil

Anil John
Thursday, September 19, 2002

I used to separate my Classic ASP in ASP files and COM components. That is code separation! I never had problems with form handlers, either. In classic ASP you can have more than one form, when that makes sense. When it doesn't, just name the submit buttons differently and read which button the user clicked.

ASP.NET makes some of this chores easier. Next I hope the developer-designer interaction will improve. Now I find changing the html design after coding harder than ever.

Thomas Eyde
Friday, September 20, 2002

So now I know why they call it "Code Behind", the code is behind the visual presentation layer (or curtain).

Does that mean the designer of the visual interface must use an IDE that works with .NET, say for example to create a web page. because the web page needs to reference the objects in the code file, or can the web page contain simple tag based tokens that get parsed out at runtime?

If they would have to use an IDE for .NET, I might have a fight on my hands, as many designers are dedicated to their current IDE's and would not see the value in learning the .NET IDE.

Is there methods to import a design from a file?

steve wasiura
Friday, September 20, 2002

That actually is one of the beauties of the whole thing. You actually do not have to use VS.NET or any other IDE to implement Code Behind. Any old text editor will do.

Say I have a code-behind file called "CodebehindNet.cs" which in turn contains a class called MyClass.

like so:
------------------
using System;
using System.Web;
using System.Web.Mail;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;

namespace Demo
{
    public class MyClass: System.Web.UI.Page
    {
                  // Your code here
                }
}
------------------


In order to call the above code-behind in my presentation file, I would simply put the following directive at the top.

<%@ Page language="c#" Src="CodebehindNet.cs" Inherits="Demo.MyClass" %>

- Anil

Anil John
Friday, September 20, 2002

BTW, most visual designers that I know of use the Photoshop/Dreamweaver combo for look and feel.

Dreamweaver MX natively supports ASP.NET.

- Anil

Anil John
Friday, September 20, 2002

The designers can use whatever IDE they want to, as long as the html renders in .NET and their IDE.  The problem starts here:

1. Designer creates HTML page
2. He gives the page to me.
3. I hook some server controls in place of his buttons, add a form, and the codebehind reference. 
4. I give it back to him for changes, while I work on the codebehind.
5. He gets it, tries to render it in HTML, but there is all this ASP.NET specific stuff in it (<asp:textbox>, <% src="main.aspx.cs">, etc.).  Also, the page doesn't render properly for him because the form screws up the page.  So he starts chopping stuff out of the page.  Then he gives it back to me.
6. I get it, and things don't work....

It would be nice if there was yet another abstraction:

A. A HTML only page that contained only HTML-compliant tags.  (The designer would only work with this file)

B. An intermediate page that would provide HTML tag substitutions/inclusions.  (The developer would edit this file to make substitutions/inclusions into the HTML-only page).  This intermediate page provides the transformation commands to transform the HTML-only page into the ASPX page.

C.  The ASPX page is then the transformation of the HTML page via the intermediate page (very similar to transforming XML to HTML via an XSLT transform stylesheet).

Now the procedure is:
1. Designer creates HTML-ONLY page
2. He gives the page to me.
3. I look at the HTML and determine what inclusions/substitutions that I should make to transform this page into the ASPX page (for instance, replacing a block of HTML with a form). 
4. I run the transformation and view it in a browser to make sure it is right, I ask him to stop by and take a look at it, also.
5. If the transform is okay, I can start working on the ASPX and the codebehind page.  Meanwhile, his HTML hasn't changed and he can continue his work.

Any comments on this?

Tim
Friday, September 20, 2002

If the designer is not working in a tool that does not recognize asp.net tags, an option to consider would be to, when possible, use HTML server controls instead of Web Form controls.

They are existing HTML constructs that actually run on the server and should be very familiar to designers.

Anil

Anil John
Friday, September 20, 2002

It's not .Net, but Zope Page Templates (http://www.zope.org) does pretty much what you're describing. Instead of using custom tags, you use the existing HTML markup with extra attributes. Editors should ignore the extra attributes, the browser will also ignore them, and when rendered by the server it will replace those tags with their dynamic content.

I'm sure something like it could be fairly easily added to .NET. Hmm... maybe a new project for me. :-)

Chris Tavares
Sunday, September 22, 2002

Chris,

Interesting to hear that about the Zope Page Templates. 

That is exactly what the HTML server controls do in ASP.NET.  There is an extra attribute called runat="server" that you add to an HTML control which turns it into a control that is accessible on the server-side.

- Anil

Anil John
Monday, September 23, 2002

*  Recent Topics

*  Fog Creek Home