Introduction to ASP.Net

So you're giving ASP.Net a whirl.  Congratulations!  ASP.Net is a pretty nice platform for developing web applications.  It has a lot of power and is pretty easy to use, once you get to know it.  However, the model for programming in ASP.Net is different than some other languages you may have worked with; if you're not careful you can end up making serious mistakes, making things a lot harder than they need to be, or just deciding that the platform is absolutely horrible for reasons that are completely, well... wrong.  This is especially true if you come from a Classic ASP background, because ASP.Net is deceptively similar in many ways and it's easy to fall into old-- and now bad-- habits.

Let's get started.
 
We'll begin with an environment like Classic ASP or PHP.  They may seem to be very dissimilar languages, but they have some similarities in certain areas.  I'm not talking about object names or syntax, but the model through which the code is interpreted.  They happen to share a model that looks something like this:

1. The browser sends a request for an .asp or .php page to the server.
2. Because it's a .asp or .php file the web server knows to pass the file through the ASP or PHP processor before sending it on.
3. The ASP or PHP processor will read through the file. Anything in special tags (<%, <?, etc) is interpreted on the fly, everything else is sent on as is.
4. Code segments that you want to reuse across your site are placed in additional ASP or PHP files that are included with the main page.
   

If you're reading this article, you may be thinking that you've seen enough.  You were all set to try ASP.Net and now I've talked you out of it.  You already know a language like PHP or ASP, and since this language is the same, why should you care?  You can go on coding like you always have.   There are a number of answers to this question: more ways to re-use code, faster development times by using the new tags that automate common tasks, the ability to separate your code from your markup/presentation, and performance.  Just because you could use ASP.Net the same way as PHP or ASP doesn't mean it is meant to work that way.
 
Performance

I'll begin with performance.  This is the least reason to use ASP.Net, and I'm not even sure it's really there anyway, but performance does matter.  For a desktop application cpu cycles and ram are plentiful, but for a web application good performance can be the difference between needing one web server or a server farm running your app.  To understand the potential performance gains of ASP.Net you have to learn some history.  I'll try to be brief. 

In the beginning was machine code.  And from machine code eventually came the compiled and interpreted languages we have today.  Compiled languages are generally considered to be faster than interpreted languages.  I'll leave that debate for another time, just know that in the beginning of the web it was a generally accepted fact.  When the time came to create a server-side web language, performance being absolutely critical in those days of 33Mhz processors, a compiled language was chosen.  Thus we had C++ cgi programs driving pages.  Unfortunately, it turns out there is some overhead in creating a new process, and web servers typically will receive numerous requests for very small programs resulting in many many processes and a lot of overhead. 

A little time passes.  Machines and interpreters get better and faster.  It was discovered that the penalty for creating the processes in a web page was greater than that of an interpreter running in process with the web server.  This brings us to the present, where interpreted languages like PHP, ASP, Ruby, and Python are all the rage for web development.  You don't see as much cgi anymore.

This matters to ASP.Net because the application code lives in a dll that is compiled all the way to native machine language,* but runs in process with the ASP.Net processer (the .Net framework).  This means you should get a performance boost just for using ASP.Net -- the best of both the compiled and interpreted worlds.  In practice, I've noticed you may end up sending more requests to the server because every action can cause the page to be rebuilt.  In my opinion this largely makes a wash of any performance benefit, but should still be considered a "good thing".  The additional requests can generally be seen in terms better response to the user or new features added by the developer.  You get what you pay for, so to speak.  This fits with the history of computer programs; as soon as we find a way to get more computer resources developers will find something to do with those resources.

Controls

Early I mentioned some 'new tags' you can use with ASP.Net.  Lets talk about how they fit into the picture.  These new tags are called 'controls'.  Here are a few examples: <asp:gridview>, <asp:literal>, <asp:repeater>, <asp:panel>, <asp:textbox>.  You can make your own controls, which is an important part of ASP.Net.  You can think of these controls, in one sense, as a transformation.  The ASP.Net processor will read the controls and transform them --or render them--  into HTML. The HTML created depends on properties you set for the controls.

Some of these controls also operate at a much higher level than normal html elements and can be complex, with many sub tags and properties.  Good examples are the Wizard and Login controls. The repeater control also bears mentioning, and there are components with built in logic for things like paging of tabular data.  These all help the developer be more productive.  It's important to remember that you can dictate every aspect of how the HTML for a control will be rendered, though some bits are harder to change than others.  If you want to do enough work you can get the same HTML from a textbox as a gridview, and vice versa.

At this point you may be wondering how the processor knows to use the dll file.  Controls also act as placeholders or anchor points for application logic located in the dll file.   The source code for this logic is not in the .aspx file at all.  Because the application logic is located elsewhere, it is very easy to have a specialized graphic designer build your page layout and a separate programmer build the code.

Code-behind and Events

Now it's getting confusing.  First I said you could use ASP.Net just like PHP or ASP.  Now I'm saying application logic isn't located in the .aspx file.  What's the deal?  Where do you put your source code?  Remember, I said that just because you could use ASP.Net like ASP or PHP doesn't mean that's how ASP.Net is meant to work.  The application logic in an ASP.Net application generally lives in a .vb or .cs file with the same name as the page, called a code-behind file.  The code in this file is capable of replacing almost all the script code that would have been included in your .aspx file.  For most sites, application code in the .aspx file can be limited to databinding expressions or even none at all.

Let me explain how this works.  Some special javascript is included in ASP.Net pages that let the new controls fire 'events', which will cause the page to post back to... itself. When this happens the page is rebuilt (and built from scratch, every time).  The framework knows what event was called, and it is very easy to have application logic that executes only when that event is fired.  More than one event can be processed when a page is built.  For example, the page itself will almost always have a Load event, and several controls may need to process their own version of that event as well.  In addition, you may have a Click event for a button that you need to process.   The source code for these events lives in the code-behind file.

You can do some neat things with the events, like hiding, showing, changing, deleting or adding new controls to the page, saving data to a database, and more.  This all happens at runtime depending on the event, results of a database query, or other factors.  The code-behind file for every page in a Visual Studio Web project, plus any class files in the project, are compiled into a single dll.  Because the code is compiled, it is not necessary to deploy code-behind files to the final site-- only the dll is needed.

Implications

This brings up some things we need to consider.  First of all, we need to setup a new web application in IIS for the ASP.Net processor to be able find the dll file.  Each Visual Studio project needs it's own application.  This can usually be done just by creating a virtual directory.  It is also needed to tell IIS which ASP.Net processor to use (ie, .Net 1.1 vs 2.0) and set the scope for shared/static variables used in the application.

Another consideration is that you'll want to become familiar with Visual Studio.  Visual Studio automatically creates and links your code-behind file, and makes it much easier to create new event handlers.  It also takes care of compiling the dll for you.  It might be possible to get by with only a text editor and the command line compiler, but I doubt anyone does it this way.  Through Intellisense, Visual Studio makes it very easy to find and use items in the .Net Framework you didn't know were there and avoid re-inventing the wheel.  There may be a third party IDE that approximates the functionality Visual Studio provides to ASP.Net, but this is Microsoft's technology.  Expect to get the best results from Microsoft's tool.

You should now have enough information to begin building a site in ASP.Net.  There are a few additional quirks like the page lifecycle and viewstate you'll need to be aware of.  However, I think that understanding this model is the first step to producing good ASP.Net pages.

* By default, code is compiled to MSIL (similar to java's bytecode).  The first time the page is viewed the IL is compiled to native langauge.  You can force your pages to be compiled to native language before the page is ever viewed.