An ASP.NET page is based on a single form component that contains all of the input elements the user can interact with. The form can also contain submission elements such as buttons or links.

A form submission sends the content of the current form to a server URL—by default, the same URL of the current page. The action of posting content back to the same page is known as the postback action. In ASP.NET, the page submits any content of its unique form to itself. In other words, the page is a constituent block of the application and contains both a visual interface and some logic to process user gestures.

The click on a submit button or a link instructs the browser to request a new instance of the same page from the Web server. In doing so, the browser also uploads any content available in the (single) page’s form. On the server, the ASP.NET runtime engine processes the request and ends up executing some code. The following code shows the link between the button component and the handler code to run:

<asp:Button runat="server" ID="Button1" OnClick="Button1_Click" />

The running code is the server-side handler of the original client-side event. From within the handler, the developer can update the user interface by modifying the state of the server controls, as already shown and as reiterated here:

public void Button1_Click(object sender, EventArgs args)
{
    // Sets the label to display the content of the text box
    Label1.Text = "The textbox contains: " + TextBox1.Text;
}

At the time the handler code runs, any server controls on the page have been updated to hold exactly the state they had during the last request to the page, plus any modifications resulting from posted data. Such stateful behavior is largely expected in a desktop scenario; in ASP.NET, however, it requires the magic of page postbacks.

The view state is a dictionary that ASP.NET pages use to persist the state of their child controls across postbacks. The view state plays an essential role in the implementation of the postback model. No statefulness would be possible in ASP.NET without the view state.

Before ASP.NET, in classic, VBScript-based ASP, developers frequently used hidden fields to track critical values across two successive requests. This approach was necessary when multiple HTML forms were used in the page. Posting from one would, in fact, reset any values in the fields within the other. To make up for this behavior, the values to track were stored in a hidden field and employed to programmatically initialize fields during the rendering of the page.

The view state is just an engineered and extended version of this common trick. The view state is a unique (and encoded) hidden field that stores a dictionary of values for all controls in the (unique) form of an ASP.NET page.

By default, each page control saves its entire state—all of its property values—to the view state. In an average-sized page, the view state takes up a few dozen KBs of extra data. This data is downloaded to the client and uploaded to the server with every request for the page. However, it is never used (and should not be used) on the client. The size of the view state has been significantly reduced over the years, but today the view state is still perceived as something that has a heavy impact on bandwidth.

It is definitely possible to write pages that minimize the use of the view state for a shorter download, but the view state remains a fundamental piece of the ASP.NET Web Forms architecture. To eliminate the view state from ASP.NET, a significant redesign of the platform would be required.

ASP.NET 4 introduces new features that deliver to developers more control over the size of the view state without compromising any page functionality.

Server controls are central to the ASP.NET Web Forms model. The output of an ASP.NET page is defined using a mix of HTML literals and markup for ASP.NET server controls. A server control is a component with a public interface that can be configured using markup tags, child tags, and attributes. Each server control is characterized by a unique ID and is fully identified by that.

In the ASP.NET page markup, the difference between a server control and a plain HTML literal string is the presence of the runat attribute. Anything in the source devoid of the runat attribute is treated as literal HTML and is emitted to the output response stream as is. Anything flagged with the runat attribute is identified as a server control.

Server controls shield developers from the actual generation of HTML and JavaScript code. Programming a server control is as easy as setting properties on a reusable component. When processed, though, the server control emits HTML. In the end, programming server controls is a way of writing HTML markup without knowing much about its unique syntax and feature set.

Server controls consume view state information and implement postback events. In addition, server controls are responsible for producing markup and do that without strictly requiring strong HTML skills on your end.

To code AJAX features, developers need to make clear and reliable assumptions about the structure of the Document Object Model (DOM) displayed within the browser. It turns out that smart black boxes, which are what ASP.NET server controls were initially conceived as, are no longer ideal tools to build Web pages.

Developers need to be sure about the layout of the HTML being output; likewise, developers need to control the ID of some internal elements being inserted into the resulting DOM. The adoption of the Web model in a large area of the industry and the public sector has resulted in the creation of applications with a potential audience of a few million people—not necessarily power users, perhaps users with disabilities, and not necessarily users equipped with the latest version of a given browser. And still developers are tasked with ensuring that all of this heterogeneous audience has the best experience and a common interface.

As you can see, the advent of AJAX brought about the complete turnaround of one of the ASP.NET pillars. Originally designed to favor independence from HTML, ASP.NET is now asked to favor a programming model that heralds total control over HTML. As you’ll see in the rest of the book, although this is far from being a mission-impossible task, it requires you to pay much more attention to how you configure controls and design pages. It also requires you, on your own, to attain a lot more awareness of the capabilities of the platform.

ASP.NET made the Web really simple to work with and made every developer a lot more productive. To achieve this result, ASP.NET was designed to be UI focused. All you do as a page developer is author pages and the code that runs behind the page.

The page gets input; the page posts back; the page determines the output for the browser. The underlying model leads you to perceive any requests simply as a way to generate HTML through a page. The page entity dwarfs anything else; you don’t really see any correspondence between a request and a subsequent server action. All you see is an incoming HTTP request and a server page object that takes care of it and returns HTML.

In this model, there’s no clear separation between the phase of processing the request to grab raw data to be incorporated in the response (for example, a list of records to be displayed in a grid) and the phase of formatting the raw data into an eye-catching, nice-looking layout.

Again, you’ll see in the rest of the book that achieving separation between processing and rendering is definitely possible in ASP.NET Web Forms and is not at all a mission-impossible task. However, it requires that you pay a lot more attention and have more discipline when it comes to writing pages and the code behind pages. Figure 1-2 extends the schema of Figure 1-1 and provides a more detailed view of the page-based pattern used to process requests in ASP.NET Web Forms. (I’ll return in a moment to the Page Controller pattern.)

Figure 1-2. ASP.NET request processing and HTML rendering.

The entire processing of an HTTP request is done by progressively updating the state of the server controls the page is made of. At the end of the cycle, the current state of controls is flushed to the response output stream and carried to the browser. The entire cycle is based on the idea of building a page, not performing an action and showing its results.

For years, this aspect of Web Forms was just accepted for what it was, with no special complaints and some praises. Today, the growing complexity of the business logic of applications built on top of the ASP.NET platform raises the need for unit tests and static analysis that are harder to set up in a runtime environment strongly focused on the plain UI.

Again what was a huge winning point in the beginning is now slowly turning into a significant weakness.

The view state is a fundamental element of the ASP.NET puzzle because it allows for the simulated statefulness of the Web Forms model. Many developers who recently embraced ASP.NET MVC—the alternate framework for ASP.NET development fully integrated in Visual Studio 2010—still find it hard to understand that each view can have shared data that must be refilled even though nothing in the request processing happened to modify it. More simply, it is the lack of view state that keeps any UI element (grids, drop-down lists, and text boxes) empty until explicitly filled on each and every request.

The view state has always been a controversial feature of ASP.NET. Starting with ASP.NET 2.0 (some five years ago), however, Microsoft introduced significant changes to the internal implementation of the view state and reduced the average size of the view state hidden field by a good 40 percent.

The view state is functional only to an application model extensively based on server controls and using server controls extensively to generate HTML. At a time when architects question the applicability of the classic ASP.NET model to their applications and look for more client-side interaction, separation of concerns (SoC), and control over the markup, the view state feature—a pillar of ASP.NET—is not that significant. Hence, it is now, more than ever, perceived as deadweight to get rid of.

The ASP.NET Web Forms model resolves an incoming request by dispatching the request to an HTTP handler component. (An HTTP handler component is simply a class that implements the IHttpHandler interface.) According to the ASP.NET Web Forms model, the HTTP handler is expected to return HTML for the browser. (You’ll find out more about HTTP handlers in Chapter 4.) The way in which the HTML for the browser is prepared is strongly oriented to the creation of a Web page. The pattern behind this approach is the Page Controller pattern.

The pattern envisions the processing of a request as a task that goes through a number of steps, such as instantiating the page, initializing the page, restoring the page’s state, updating the page, rendering the page, and unloading the page. Some of these steps have been rendered in Figure 1-2, and all of them will be discussed in detail in Chapter 2 and in Chapter 3.

In the implementation of the pattern, you start from a base page class and define a strategy to process the request—the page life cycle. In the implementation of the page life cycle, you come up with an interface of virtual methods and events that derived pages will have to override and handle. (See Figure 1-3.)

Figure 1-3. The internal page life cycle exposed to user code via page controller classes.

Derived page classes are known as code-behind classes in ASP.NET jargon. Writing an ASP.NET page ultimately means writing a code-behind class plus adding a description of the user interface you expect for it. The code-behind class is the repository of any logic you need to serve any possible requests that can be originated by the input elements in the page. A code-behind class derives from a system class—the System.Web.UI.Page class.

Taken individually, a code-behind class is simply the “controller” object responsible for processing a given request. In the context of an application, on the other hand, it can lead you to building a small hierarchy of classes, as shown in Figure 1-4.

Figure 1-4. A sample hierarchy of classes.

Your code-behind class can inherit from the system base class or from intermediate classes with a richer behavior. Developers can extend the hierarchy shown in the figure at will. Especially in large applications, you might find it useful to create intermediate page classes to model complex views and to fulfill sophisticated navigation rules. Building a custom hierarchy of page classes means placing custom classes in between the page controller and the actual code-behind class.

The ultimate reason for having a custom hierarchy of pages is to customize the page controller, with the purpose of exposing a tailor-made life cycle to developers. An intermediate class, in fact, will incorporate portions of common application behavior and expose specific new events and overridable methods to developers.

Today the main focus of Web architectures is more oriented toward the action rather than the concrete result. This is essentially because of a paradigm shift that generalized the use of the Web tool—it’s no longer just a way to get HTML pages but is a lower level producer of data with its own (variable) representation.

To serve the needs of the new Web, you probably don’t need all the thick abstraction layer that purposely was added on top of the Web Forms model ten years ago with the precise goal of simplifying the production of the sole conceivable output—the HTML page.

A framework like ASP.NET MVC—even though it is built on the same runtime environment as ASP.NET Web Forms—will always adhere more closely than ASP.NET Web Forms to the new paradigm. It’s a matter of structure, skeleton, and posture; it’s not a matter of gesture or behavior. However, there’s some room for teams of developers to revisit the Web Forms model and change its posture to achieve benefits in terms of both testability and separation of concerns.

Revisiting the Page Controller pattern today means essentially taking into account design patterns that privilege separation of concerns between involved parts of the system. This probably doesn’t mean that you can rearrange the entire page life cycle—you need a new framework for that similar to ASP.NET MVC—but you can restructure some portions of the page life cycle to isolate portions of code as distinct components that are testable and writable in isolation.

For example, revisiting the Page Controller pattern means applying the Model View Presenter (MVP) pattern to decouple the implementation of the postback mechanism with the subsequent rendering of the view. We’ll get back to this topic in Chapter 15.

In the end, in the second decade of the 2000s ASP.NET Web Forms is approaching an architectural dead end. On one hand, it is recommended that you do not unconsciously ignore newer frameworks (for example, ASP.NET MVC); on the other hand, however, Web Forms is still highly effective, mature, and functional and certainly doesn’t prevent you from achieving great results.

Whether you’re considering shifting to ASP.NET MVC or sticking to Web Forms, it is essential that you reconsider the design and architecture of your views and pages. The classic Page Controller pattern is getting obsolete and needs solutions to make it more testable and layered. An effective Web Forms application today needs separation of concerns, interface-based programming, and cohesive components. No framework will give you that free of charge, but with Web Forms you need a great deal of awareness and commitment.

According to Wikipedia, a paradigm shift describes a change in most of the basic assumptions within the ruling theory of a science. The shift creates a break and clearly contrasts with the current ideas and approaches. A paradigm shift is a long process that begins naturally when enough significant limitations and anomalies have been found within the current state of the art in a discipline.

At this point, new ideas are tried—often ideas that were considered years before and then discarded. The community proceeds by trial and error, experimenting and trying to come to general conclusions. Inevitably, a paradigm shift puts the discipline into a state of crisis. (This is the term used by Thomas Kuhn, who coined the term paradigm shift and formalized these concepts.) The state of crisis manifests itself through a number of attempts to change, each presented as possibly definitive but that hardly work for everybody, at least in the original form.

The impact of a paradigm shift is particularly deep in areas that appear to be stable and mature. A great example of a paradigm shift is the changes in physics at the beginning of the twentieth century. Before the advent of Einstein’s theory of relativity, physics was unanimously considered to be a largely worked-out system. The theory of relativity he formulated in 1905 changed everything in the field, but it was only about three decades later that the process of redefining the fundamentals of physics was completed. For more information, pay a visit to http://en.wikipedia.org/wiki/Paradigm_shift. It’s definitely illuminating reading.

So now, how does this apply to ASP.NET and AJAX?

Even though we tend to date the advent of AJAX around the 2004, one of the core tools of AJAX—the XmlHttpRequest object—is much older. In the late 1990s, we already had all the technologies we are using today to set up AJAX solutions. For a number of reasons, the idea of using JavaScript, the HTML DOM, and the XmlHttpRequest object to update pages asynchronously was discarded for most applications, even though Outlook Web Access and a number of niche applications continued using it.

It was tried again in the early 2000s, and this time it really stuck.

Like physics in the early twentieth century, ASP.NET Web Forms was a stable and mature platform when AJAX experiments started. In the beginning, it was simply a matter of spicing up some pages with a piece of JavaScript code and downloading raw data from an HTTP endpoint. However, it is one thing to download a number or a string and refresh the small portion of the user interface that contains it, but it’s quite another to download a collection of data objects to repopulate a grid. And what if you intend to post the content of a form and then update a large section of the current view?

The underlying machinery and tools remain the same, but the way in which they are organized, exposed to developers, and consumed requires a lot of thinking and perhaps a brand new application model.

In particular, the advent of AJAX raised the need for developers to embed more JavaScript code in HTML pages. The JavaScript code, however, has to deal with HTML DOM elements, each of which is commonly identified with a unique ID. In an ASP.NET Web Forms application, it’s the set of server controls defined in a page that ultimately determines the structure of the HTML DOM and the ID of the constituent elements.

To support AJAX deeply and effectively, Web Forms developers have to dig out some of the internal details of the server control black boxes. In doing so, developers attack one of the pillars of the Web Forms model. The more AJAX you want, the more control you need over HTML; the more control over HTML you want, the more you are mining the foundation of ASP.NET Web Forms.

But there’s more than just this.

For years, the Web worked around a Pages-for-Forms model. It was just fine in the beginning of the Web age when pages contained little more than formatted text, hyperlinks, and maybe some images. The success of the Web has prompted users to ask for increasingly more powerful features, and it has led developers and designers to create more sophisticated services and graphics. As a result, today’s pages are heavy and cumbersome. (See Figure 1-5.)

Figure 1-5. A page sends out the content of an HTML form and receives an HTML page.

Given the current architecture of Web applications, each user action requires a complete redraw of the page. Subsequently, heavier pages render out slowly and produce a good deal of flickering. Projected to the whole set of pages in a large, portal-like application, this mechanism is perfect for causing great frustration to the poor end user.

AJAX just broke this model up. A request might or might not post a form and request an entire page. More often, an HTTP request might just pass raw data and request raw data—an overall simplification of the interaction model. (See Figure 1-6.)

Figure 1-6. HTML elements fire out-of-band calls passing raw data and getting raw data, not necessarily HTML pages.

ASP.NET Web Forms was created to receive forms and return pages. It is difficult to turn it into a model that fully supports the Data-for-Data model of AJAX. Web Forms hides a lot of its machinery and offers a higher level view of the Web operation than many demand today.

This fact can’t be ignored when making architectural decisions about which platform to use for a given Web project.

It’s not relevant whether Web Forms was designed in the wrong or right way. It was right for the time it was designed. The advent of AJAX created different business conditions; in these conditions, Web Forms is not necessarily the ideal framework.

But is there any ideal ASP.NET framework out there?

A decade ago, we just wanted applications deployed through the Web. And Web Forms worked just fine to satisfy us. Later on, we wanted richer applications that were quicker and smoother to use and more responsive. And a good set of AJAX capabilities added to Web applications made us happier as end users.

What about developers?

We probably completed the step of understanding what kind of Web applications we want to serve to our users. We don’t yet have an effective set of developer tools to make the creation of modern Web applications quick, easy, and productive—in one word, effective. So we’re in search of the perfect framework. Developers need to build user interfaces to be served and consumed over the Web and within a Web browser. Such a framework must simplify a number of common tasks. Here’s a list of the capabilities we expect:

In terms of technologies, we definitely need a rich client infrastructure, a simple controller component to parse HTTP requests and dispatch commands to the back end, and we need a layered architecture to keep business tasks separate from presentation and data access.

The development team is directly responsible for the architecture and for adding as many layers as they think are necessary. The framework, on the other hand, should simplify the other aspects and provide smooth integration between client and server code and naturally and effectively process the incoming requests. We don’t yet have the perfect framework. It will probably take a couple more years for this to materialize. But we see all around signs of libraries and tools being consolidated.

The family of jQuery libraries (including the jQuery UI library and various plug-ins) seems to be the catalyst for dynamic user interfaces; ASP.NET MVC seems to be the simpler framework to start with and to build new made-to-measure abstractions. Abstraction is still important because it’s only via abstraction that you build productivity.

Whatever emerges as the ideal ASP.NET framework for the next decade, my guess is that it will build on jQuery and most of the principles and solutions in ASP.NET MVC. ASP.NET Web Forms today is in the middle of a transition. It is neither the future nor the past. It can be adapted and still be effective. It requires an awareness of the changes, in business and subsequently architecture, we are experiencing.

Basically, there are two ways in which you can incorporate AJAX into a Web framework. I like to refer to them as selective updates and direct scripting.

You perform a selective update when you execute a server action and then return a chunk of HTML to selectively update the current view. This approach descends from the HTML Message AJAX pattern as summarized at http://ajaxpatterns.org. The trick is all in bypassing the browser when a request—form post or hyperlink—has to be submitted. You place a script interceptor at the DOM level (for example, a handler for the Form DOM object submit event), capture the ongoing request, cancel the operation, and replace it with your own asynchronous implementation. When a response is received, it is assumed to be HTML and integrated into the current DOM at a given location.

An ASP.NET framework that fully supports the Selective Update model will specify details for how the script interceptor has to be defined and for how the current view has to be modified. In ASP.NET Web Forms, the Selective Update model is implemented via partial rendering. In ASP.NET MVC, it comes through the services of the AJAX HTML helper.

Direct scripting is plain JavaScript code through which you connect to a remote endpoint to send and receive data. You likely rely on a rich JavaScript framework (for example, jQuery) and use the JSON format to move complex data around.

In my opinion, the Direct Scripting model is good for little things that can improve a feature of the user interface. I don’t see the Direct Scripting model growing to become the reference pattern for AJAX applications. To be effective, direct scripting requires an ad hoc architecture and a new set of standards. Rich Internet Application (RIA) services and open protocols such as Open Data (oData) and Open Authorization (oAuth) are coming out, but direct scripting remains an option for a subset of sites and applications.

I wouldn’t pick up direct scripting as the solution for a unified programming model that accommodates the server-side Web and the client-side Web. Why not? With direct scripting, you are indissolubly bound to JavaScript and HTML. This is certainly great for some applications, but not for all.

To achieve direct scripting capabilities, today you have to look in the direction of the jQuery library and its plug-ins. I’ll cover jQuery in Chapter 21.

ASP.NET MVC is a completely new framework for building ASP.NET applications, designed from the ground up with SoC and testability in mind. With ASP.NET MVC you rediscover the good old taste of the Web—stateless behavior, full control over every single bit of HTML, and total script and CSS freedom.

Processing the request and generating the HTML for the browser are distinct steps and involve distinct components—the controller and the view. The controller gets the request and decides about the action to take. The controller grabs the raw response and communicates it to the view engine for the actual writing onto the browser’s output stream.

In ASP.NET MVC, there’s no dependency on ASPX physical server files. ASPX files might still be part of your project, but they now serve as plain HTML templates that the default view engine uses as a template for creating the HTML response for the browser. When you author an ASP.NET MVC application, you reason in terms of controllers and actions. Each request must be mapped to a pair made by a controller and an action. Executing the action produces data; the view engine gets raw data and a template and produces the final markup (or whatever else it is expected to produce, such as JSON or JavaScript). Figure 1-7 shows the sequence of steps that characterize a typical ASP.NET MVC request.

Figure 1-7. The sequence diagram for an ASP.NET MVC request.

The runtime environment that supports an ASP.NET MVC application is largely the same as in ASP.NET Web Forms, but the request cycle is simpler and more direct. An essential part of the Web Forms model, the page life cycle, is now just an optional implementation detail in ASP.NET MVC. Figure 1-8 compares the run time stack for Web Forms and ASP.NET MVC.

Figure 1-8. The run-time stack of ASP.NET MVC and Web Forms.

As you can see, the run-time stack of ASP.NET MVC is simpler and the difference is due to the lack of a page life cycle. As mentioned earlier, the page life cycle and the entire thick abstraction layer built by Web Forms saves the developer a lot of work.

ASP.NET MVC is closer to the metal, and this has its own side effects. If you need to maintain state, that is up to you. For example, you can store it into Session or Cache, or you can even create, guess what, your own tailor-made, view state–like infrastructure. In the end, the simplicity of ASP.NET MVC is due to different architectural choices rather than to some overhead in the design of the Web Forms model.

So ASP.NET MVC brings to the table a clean design with a neat separation of concerns, a leaner run-time stack, full control over HTML, an unparalleled level of extensibility, and a working environment that enables, not penalizes, test-driven development (TDD).

ASP.NET Web Forms and ASP.NET MVC applications can go hand in hand and live side by side in the same process space. The runtime environment must be configured to host an ASP.NET MVC application. This means installing a routing module that intercepts requests at the gate and decides how they are to be processed. An ASP.NET MVC application lists one or more URL patterns it will accept. Requests whose URL matches any defined patterns are processed as ASP.NET MVC requests, while others are left to the standard processing engine of Web Forms.

Just like with Web Forms, what some perceive as a clear strength of ASP.NET MVC, others may see as a weakness. ASP.NET MVC doesn’t offer server controls of its own and also severely limits the use of classic ASP.NET server controls. Even though you describe the view of an ASP.NET MVC page via ASPX markup, you can’t embed in it server controls that handle postbacks. In other words, you are allowed to use a DataGrid if your goal is creating a table of records, but your code will receive an exception if the DataGrid is configured to allow paging, sorting, or inline editing.

To gain full control over HTML, JavaScript, and CSS, ASP.NET MVC requires that you write Web elements manually, one byte after the next. This means that, for the most part, you are responsible for writing every single <li> or <table> tag you need. In ASP.NET MVC, there’s no sort of component model to help you with the generation of HTML. As of today, HTML helpers and perhaps user controls are the only tools you can leverage to write HTML more quickly. Overall, some developers might see ASP.NET MVC as taking a whole step backward in terms of usability and productivity.

Adding visual components to ASP.NET MVC is not impossible per se; it is just arguably what most users of the framework really want. My opinion is that keeping any form of markup abstraction far away from ASP.NET MVC is OK as long as you intend to have two distinct frameworks for ASP.NET development. But I do hope that we move soon to a new framework that unifies the Web Forms and ASP.NET MVC models. In this new framework, if it ever arrives, I do expect some markup abstraction as the only way to increase productivity and have people move to it.

Simplicity is a characteristic that is often associated with ASP.NET MVC. If you look at Figure 1-8, you can hardly contest the point—ASP.NET MVC is architecturally simpler than Web Forms because the sequence of steps to process a request follows closely the rules of the underlying protocols, with no abstractions created by the framework.

This is a correct statement, but it is a bit incomplete. ASP.NET MVC processes a request through an action and passes return values to a view engine. In doing so, though, ASP.NET MVC offers a number of free services that you might or might not need. For example, when a form posts its content, the framework attempts to bind posted data to the formal parameters of the action method in charge of serving the request. There’s a lot of reflection involved in this approach, and some work is done that might not strictly be needed. Can you opt out of this model binding, and how easy is it to do so?

This is the point that shows why ASP.NET MVC targets simplicity in a much more effective way than Web Forms.

In ASP.NET MVC, opting out of a built-in feature simply requires that you use a different coding convention. There’s nothing to disable and no closure to crack open to get a different behavior. Any complexity in ASP.NET MVC is built in a bottom-up manner, by composing layers of code one on top of the other. At any time, you can step back and remove the topmost layer to replace it or simply do without it.

In Web Forms, opting out of any built-in feature is much harder because the framework was deliberately built around them in a top-down manner. You can still create HTML-based pages in Web Forms, but it will be significantly hard and counterintuitive. To alter the default behavior of Web Forms, you have to resort to tricks or override methods. In ASP.NET MVC, you just change your programming style or simply replace the component.

ASP.NET Web Pages targets an audience of Web developers who are involved in very simple projects either because they’re not software specialists or because the site to create is extremely simple indeed. This audience would benefit from even further simplicity such as a single page model and a simplified way of writing code and the view. ASP.NET Web Pages comes with a new IDE called WebMatrix and a simplified version of IIS, aptly named IIS Express. WebMatrix, in particular, wraps up server code, markup, and database tables in a new designer environment that makes it a snap to write pages and publish them to a site.

With ASP.NET Web Pages, you write pages using a mixed syntax that incorporates both markup and code, but in a way that is a bit cleaner than today with either Web Forms or ASP.NET MVC code blocks. By using the @xxx syntax, where xxx is a built-in object, you can insert in the markup some dynamically calculated value and also use those components to emit ad hoc markup. Here’s an example:

<body>
   Today is @DateTime.Now
</body>

Such objects are more similar to ASP.NET MVC HTML helpers than to Web Forms controls, and they represent dynamic code you can interact with in a single environment while building the output you expect.