text: .
  Almost from it’s beginning, HTML has been a mixture of data, display and logic. While the original static pages might have only combined data and display, once scripting was introduced the three disciplines have lived together uncomfortably. ASP only made this situation worse by introducing a different location (the server) where the scripting code could be executed.
  Ugly doesn’t adequately describe this problem. There is little possibility for functional reuse in this scenario. It is difficult even to modify existing business logic, much less make sure that it’s capable of being using by other components. This is not how enterprise-class applications are suppose to be created.
  While ASP.NET supports this older processing model (known as in-line), it also introduced a newer model known a code-behind. While this particular model doesn’t eliminate the data/display co-mingling, it does take the business logic away from the web page. Instead, the events are handled by methods in a separate class. The code behind class. Let’s take a brief look at how these pieces (the ASPX page and the code behind class) get wired together.
  Above is a standard, if simplistic, ASPX page. Were it not for that first line, it would look like pretty much a run-of-the-mill HTML page. And it’s that first line that brings the code-behind class into play.
  That first line is known as the page directive. When the ASPX file is processed, the directive is interpreted to mean that a) the language in any of the script blocks in the file will be in C# and b) that the processor should use methods in ObjectSharp.WebPageClass to handle the events raised by the web form. As an example, this means that the MyButton_Click method (seen above as the Onclick event handler for MyButton) would be implemented in the assembly that contains the ObjectSharp.WebPageClass class.
  The final item of note for this class definition are the three protected variables MyLabel, MyButton and MyTextBox. You might have noticed that they correspond, by name and type, to the three elements of the example ASPX page that have asp: as the element’s namespace qualifier. That is not a coincidence. By utilizing that asp: qualifier, a corresponding object is created in the code-behind. Then when the methods of the object are manipulated within the code-behind class, the values on the web page are modified as well.
  In the example, the MyButton_Click method sets the Text property on MyLabel. As a result, the MyLabel control on the page that is sent back to the browser will have it’s text updated. This mapping is managed automatically by ASP.NET and has the effect of moving the web page development model much closer to the Windows Forms model. While you can accurately claim that as an abstraction the ASP.NET code-behind model is leaky, as a starting point for ASP.NET developers, it is nice to have a familiar base from which to build.
  In case you were unaware, Microsoft Canada is in the middle of running a Last Developer Standing competition. Modelled on the wildly popular (or at least, moderately watched) Last Comic Standing show on television, the idea is to give developers a series of tests. For each test, only the developers who answer the most questions correctly get to move on to the next round. What’s even better is that the final developer gets more than just good wishes…to the tune of $25,000. More information can be found at.
  So why am I mentioning this now? As part of this contest, I have been asked to blog about some of the topics that contestants will face. These posts are available on a specific feed (), as well as my main feed. So stay tuned for information that might very well be what you need to be the Last Developer Standing.