Web server in C#.NET

Encoder QR Code in C#.NET Web server

http://

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. Important More and more applications require pages rich with client code that limit the

number of postbacks and replace many postbacks with AJAX calls. In this context, Web Forms can be adapted maybe even to a great degree but the approach has some architectural limitations that must be known and taken into account. These limitations are not necessarily something that would make you lean toward an alternate framework such as ASP.NET MVC, but they also are not something a good architect can blissfully ignore.

Introduced a decade ago, ASP.NET Web Forms has evolved and has been improved over the years. Its flexible design allowed for a lot of changes and improvements to be made, and the framework is still effective and productive. Although the design of the ASP.NET framework was inspired by a totally different set of principles and priorities than the ones you would apply today, most of the alleged limitations of ASP.NET that I ve outlined so far (heavyweight pages, limited control over markup, lack of testability) can still be largely worked out, smoothed over, and integrated to serve up an effective solution. This is to say that the advent of a new framework such as ASP.NET MVC doesn t necessarily mean that ASP.NET Web Forms (and, with it, your existing skills) are out of place. There s always a strong reason for new things (frameworks in this regard) to be developed, but understanding needs, features, and capabilities is still the only proven way of dealing with hard decisions and architecture. ASP.NET Web Forms is designed around the Page Controller pattern. Let s find out a bit more about the pattern and what you can do to limit some of its current downsides.