Programming Microsoft ASP.NET 4 - Dino Esposito [115]
Summary
ASP.NET is a complex technology built on top of a substantially thick—and, fortunately, solid and stable—Web infrastructure. To provide highly improved performance and a richer programming toolset, ASP.NET builds a desktop-like abstraction model, but it still has to rely on HTTP and HTML to hit the target and meet end-user expectations.
It is exactly this thick abstraction layer that has been responsible for the success of Web Forms for years, but it’s being questioned these days as ASP.NET MVC gains acceptance and prime-time use. A thick abstraction layer makes programming quicker and easier, but it necessarily takes some control away from developers. This is not necessarily a problem, but its impact depends on the particular scenario you are considering.
There are two relevant aspects in the ASP.NET Web Forms model: the process model and the page object model. Each request of a URL that ends with .aspx is assigned to an application object working within the CLR hosted by the worker process. The request results in a dynamically compiled class that is then instantiated and put to work. The Page class is the base class for all ASP.NET pages. An instance of this class runs behind any URL that ends with .aspx. In most cases, you won’t just build your ASP.NET pages from the Page class directly, but you’ll rely on derived classes that contain event handlers and helper methods, at the very minimum. These classes are known as code-behind classes.
The class that represents the page in action implements the ASP.NET eventing model based on two pillars: the single form model (page reentrancy) and server controls. The page life cycle, fully described in this chapter, details the various stages (and related substages) a page passes through on the way to generate the markup for the browser. A deep understanding of the page life cycle and eventing model is key to diagnosing possible problems and implementing advanced features quickly and efficiently.
In this chapter, I mentioned controls several times. Server controls are components that get input from the user, process the input, and output a response as HTML. In the next chapter, we’ll explore the internal architecture of server controls and other working aspects of Web Forms pages.
Chapter 6. ASP.NET Core Server Controls
“Everything happens to everybody sooner or later if there is time enough.”
—George Bernard Shaw
ASP.NET Web Forms pages are typically made of a markup template—the ASPX file—and a back-end class—the code-behind class. In the ASPX template, you find literal text mixed with special markup tags (featuring the runat attribute) that identify server controls. In the code-behind class, you insert some request-processing logic—mostly presentation logic. So what’s the role of server controls?
Server controls are components with a declarative and programming interface used to generate a specific piece of HTML markup based on the request and associated presentation logic. As you saw in Chapter 5, anything you place in the ASPX template is mapped to a server control. The ASP.NET runtime then combines the output of all controls and serves the client an HTML response to display in a browser. The programming richness of ASP.NET springs from the wide library of server controls that covers the basic tasks of HTML interaction—for example, collecting text through input tags—as well as more advanced functionalities such as calendaring, menus, tree views, and grid-based data display.
There are two main families of server controls: HTML server controls and Web server controls. HTML server controls are implemented through server-side classes whose programming interface faithfully represents the standard set of attributes for the corresponding HTML tag. Web controls, in turn, are a more abstract library of controls in which adherence of the proposed API to HTML syntax is much less strict. As a result,