ASP.NET Development Stack

ASP.NET Development Stack-: We build the pages that form the application, implement its user’s requirements, and then fine-tune the surrounding run-time environment to make it serve pages effectively and securely.  The development of an ASP.NET application passes through two phases

  • page authoring and
  • run-time configuration.

There are many various logical layers are available in development stack. These are the..

The Presentation Layer-: An ASP.NET page is made of controls, free text, and markup. When the source code is transformed into a living instance of a page class, the ASP.NET run time makes no further distinction between verbatim text, markup, and server controls—everything is a control, including literal text and carriage-return characters. At run time, any ASP.NET page is a mere graph of controls.

Rich Controls-:  The programming richness of ASP.NET springs from the wide library of server controls that covers the basic tasks of HTML interaction as like  collecting text through input tags.

Custom Controls:- ASP.NET core controls provide us  with a complete set of tools to build Web functionalities. The standard set of controls can be extended and enhanced by adding custom controls. The underlying ASP.NET component model greatly simplifies the task by applying the common principles and rules of object-oriented programming.

we can build new controls by enhancing an existing control or aggregating two or more controls together to form a new one.

Adaptive Rendering-: Starting with version 2.0, ASP.NET ships a new control adaptor architecture that allows any server control to create alternate renderings for a variety of browsers. in asp.net provide  Mobile controls are a special family of Web controls designed to build applications for mobile devices. ASP.NET mobile controls still use the old adaptor model, which was available since ASP.NET 1.1, for controls that inherit from Mobile Control and are hosted on pages that inherit from Mobile Page.

The Page Framework-:  ASP.NET page works as an instance of a class that descends from the Page class. The Page class is the ending point of a pipeline of modules that process any HTTP request. The various system components that work on the original request build step by step all the information needed to locate the page object to generate the markup. The page object model sports several features and capabilities that could be grouped in terms of events, scripting, impersonation, styling, and prototyping.

Page Events-:ASP.NET we  find new events to signal the beginning and end of the initialization and loading phase.

Page Scripting-: The page scripting object model lets developers manage script code and hidden fields to be injected in client pages. This object model generates JavaScript code used to glue together the HTML elements generated by server controls, thus providing features otherwise impossible to program on the server. For example, in this way you can set the input focus to a particular control when the page displays in the client browser.

Cross-page posting is another feature that the community of ASP.NET developers loudly demanded. It allows the posting of content of a form to another page.

Page Personalization-: we can store and retrieve user-specific information and preferences without the burden of having to write the infrastructural code. The application defines its own model of personalised data, and the ASP.NET run time does the rest by parsing and compiling that model into a class. Each member of the personalized class data corresponds to a piece of information specific to the current user. Loading and saving personalized data is completely transparent to end users and doesn’t even require the page author to know much about the internal plumbing. The user personalized information is available to the page author through a page property. Each page can consume previously saved information and save new information for further requests.

Page Styling-:Like Microsoft Windows XP themes, ASP.NET themes assign a set of styles and visual attributes to elements of the site that can be customised. These elements include control properties, page style sheets, images, and templates on the page.

A theme is the union of all visual styles for all customisation elements in the pages—a sort of super–CSS file. A theme is identified by name and consists of CSS files, images, and control skins. A control skin is a text file that contains default control declarations in which visual properties are set for the control. With this feature enabled, if the developer adds, say, a Calendar control to a page, the control is rendered with the default appearance defined in the theme.

Themes are a great new feature because they allow you to change the look and feel of pages in a single shot and, perhaps more importantly, give all pages a consistent appearance.

Page Prototyping-: Almost all Web sites today contain pages with a similar layout. For some sites, the layout is as simple as a header and footer, others sites might contain sophisticated navigational menus and widgets that wrap content.

The HTTP Runtime Environment:- The process by which a Web request becomes plain HTML text for the browser is not much different in any version of ASP.NET. The request is picked up by IIS, given an identity token, and passed to the ASP.NET ISAPI extension (aspnet_isapi.dll)—the entry point for any ASP.NET-related processing. This is the general process, but a number of key details depend on the underlying version of IIS and the process model in use.

 

Once in the ASP.NET HTTP pipeline, the request passes through various system and user-defined components that work on it until a valid page class is found and successfully instantiated. Developers can modify and adapt the run-time environment to some extent. This can happen in a variety of ways: changing the list of installed HTTP modules, configuration files, state and personalization providers, and other application services.

System HTTP Modules-: HTTP modules are the ASP.NET counterpart of ISAPI filters. An HTTP module is a .NET Framework class that implements a particular interface. All ASP.NET applications inherit a few system HTTP modules as defined in the machine.config file. Preinstalled modules provide features such as authentication, authorization, and session-related services. Generally speaking, an HTTP module can pre process and post process a request, and it intercepts and handles system events as well as events raised by other modules.

Application Configuration-:The behaviour of ASP.NET applications is subject to a variety of parameters. some are system-level settings, and some depend on the characteristics of the application.

The common set of system parameters are defined in two files—machine.config and a machine level (global) web.config.

All together, the two files contain machine-specific values for all supported settings. Machine settings are normally controlled by the system administrator, and applications should not be given write access to both files. These files are located outside the Web space of the application and, as such, cannot be reached even if an attacker succeeds in injecting malicious code into the system.

Application Services-:
Authentication, state management, and caching are all examples of essential services that the ASP.NET run time environment supplies to running applications.

A more detailed view of the ASP.NET development stack. The arrow indicates the typical top-down application perspective, going down from the user interface to the system services.

Most application services must persist and retrieve some data for internal purposes. While doing so, a service chooses a data model and a storage medium, and it gets to the data through a particular sequence of steps. Applications based on these services are constrained by the design to using those settings—which usually include a fixed data schema, a predefined storage medium, or a hard-coded behaviour.

Run-time configuration, as achieved through machine.config and web.config files, adds some more flexibility to your code. However, run-time configuration does not provide a definitive solution that is flexible enough to allow full customization of the service that would make it extensible and smooth to implement.

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *