9866550012
ASPDOTNET INTRODUCTION DAY TWOASP.NET Web pages as the programmable user interface for your Web application. An ASP.NET Web page presents information to the user in any browser or client device and implements application logic using server-side code. ASP.NET Web pages are:
·
Based on Microsoft ASP.NET technology, in which code that runs
on the server dynamically generates Web page output to the browser or client
device.
·
Compatible with any browser or mobile device. An ASP.NET Web
page automatically renders the correct browser-compliant HTML for features such
as styles, layout, and so on.
·
Compatible with any language supported by the .NET common
language runtime, such as Microsoft Visual Basic and
Microsoft Visual C#.
·
Built on the Microsoft .NET Framework. This provides all the
benefits of the framework, including a managed environment, type safety, and
inheritance.
·
Flexible because you can add user-created and third party
controls to them.
In ASP.NET Web pages, user interface
programming is divided into two pieces:
The visual element
consists of a file containing static markup such as HTML or ASP.NET server
controls or both. The ASP.NET Web page works as a container for the static text
and controls you want to display.
The logic for the
ASP.NET Web page consists of code that you create to interact with the page.
The code can reside either in a script block
in the page or in a separate class. If the code is in a separate class file,
this file is referred to as the code-behind file.
The code in the code-behind file can be written in Visual Basic, C#, or
any other .NET Framework language.
Web application
programming presents challenges that do not typically arise when programming
traditional client-based applications. Among the challenges are:
·
Implementing a rich Web user
interface It can be difficult and tedious to design and
implement a user interface using basic HTML facilities, especially if the page
has a complex layout, a large amount of dynamic content, and full-featured
user-interactive objects.
·
Separation of client and server In
a Web application, the client (browser) and server are different programs often
running on different computers (and even on different operating systems).
Consequently, the two halves of the application share very little information;
they can communicate, but typically exchange only small chunks of simple
information.
·
Stateless execution When
a Web server receives a request for a page, it finds the page, processes it,
sends it to the browser, and then discards all page information. If the user
requests the same page again, the server repeats the entire sequence,
reprocessing the page from scratch. Put another way, a server has no memory of
pages that it has processed—page are stateless. Therefore, if an application
needs to maintain information about a page, its stateless nature can become a
problem.
·
Unknown client capabilities In
many cases, Web applications are accessible to many users using different
browsers. Browsers have different capabilities, making it difficult to create
an application that will run equally well on all of them.
·
Complications with data access Reading
from and writing to a data source in traditional Web applications can be
complicated and resource-intensive.
·
Complications with scalability In
many cases Web applications designed with existing methods fail to meet
scalability goals due to the lack of compatibility between the various components
of the application. This is often a common failure point for applications under
a heavy growth cycle.
ASP.NET Web pages
and the ASP.NET page framework address these challenges in the following ways:
·
Intuitive, consistent object model The
ASP.NET page framework presents an object model that enables you to think of
your forms as a unit, not as separate client and server pieces. In this model,
you can program the page in a more intuitive way than in traditional Web
applications, including the ability to set properties for page elements and
respond to events. In addition, ASP.NET server controls are an abstraction from
the physical contents of an HTML page and from the direct interaction between
browser and server. In general, you can use server controls the way you might
work with controls in a client application and not have to think about how to
create the HTML to present and process the controls and their contents.
·
Event-driven programming model ASP.NET
Web pages bring to Web applications the familiar model of writing event
handlers for events that occur on either the client or server. The ASP.NET page
framework abstracts this model in such a way that the underlying mechanism of
capturing an event on the client, transmitting it to the server, and calling
the appropriate method is all automatic and invisible to you. The result is a
clear, easily written code structure that supports event-driven development.
·
Intuitive state management The
ASP.NET page framework automatically handles the task of maintaining the state
of your page and its controls, and it provides you with explicit ways to
maintain the state of application-specific information. This is accomplished
without heavy use of server resources and can be implemented with or without
sending cookies to the browser.
·
Browser-independent applications The
ASP.NET page framework enables you to create all application logic on the
server, eliminating the need to explicitly code for differences in browsers.
However, it still enables you to take advantage of browser-specific features by
writing client-side code to provide improved performance and a richer client
experience.
·
.NET Framework common language
runtime support The ASP.NET page framework is built on
the .NET Framework, so the entire framework is available to any ASP.NET
application. Your applications can be written in any language that is
compatible that is with the runtime. In addition, data access is simplified
using the data access infrastructure provided by the .NET Framework, including ADO.NET.
·
.NET Framework scalable server
performance The ASP.NET page framework enables you to
scale your Web application from one computer with a single processor to a
multi-computer Web farm cleanly and without complicated changes to the
application's logic.
ASP.NET Web pages allow you to create
dynamic content for your Web application. With a static HTML page (.htm or
.html file), the server fulfills a Web request by reading the file and sending
it as-is to the browser. In contrast, when someone requests an ASP.NET Web page
(.aspx file), the page runs as a program on the Web server. While the page is
running, it can perform any task that your Web site requires, including
calculating values, reading or writing database information, or calling other
programs. As its output, the page dynamically produces markup (elements in HTML
or another markup language) and sends this dynamic output to the browser.
The processing cycle
for an ASP.NET Web page is this:
1. The user requests
the page. (The page is requested using an HTTP GET method.) The page runs for the first
time, performing preliminary processing if you have programmed it to do so.
2. The page dynamically
renders markup to the browser, which the user sees as a Web page similar to any
other page.
3. The user types information
or selects from available choices and then clicks a button. (If users click a
link instead of a button, the page might simply navigate to another page, and
no further processing takes place on the first page.)
4. The page is posted
to the Web server. (The browser performs an HTTP POST method, which in ASP.NET is referred
to as a postback.)
Specifically, the page is posted back to itself. For example, if the user is
working with the page Default.aspx, clicking a button on the page posts the
page back to the server with a target of Default.aspx.
5. On the Web server,
the page runs again. The information that the user typed or selected is
available to the page.
6. The page performs
the processing that you have programmed it to do.
7. The page renders
itself back to the browser.
This cycle continues
as long as the user is working in the page. Each time the user clicks a button,
the information in the page is posted to the Web server and the page runs
again. Each cycle is referred to as a round trip. Because page processing occurs on the
Web server, each action that the page can do requires a round trip to the
server.
When a Web
application runs, ASP.NET maintains information about the current application,
each user session, the current HTTP request, the requested page, and so on.
ASP.NET contains a series of classes to encapsulate this context information.
ASP.NET makes
instances of these classes available as intrinsic objects that you can access
from your code. The following table lists these intrinsic objects and the
classes they are instances of.
|
Object Name
|
Description
|
ASP.NET Class
|
|
Response
|
Provides access to the output stream for the current
page. You can use this class to inject text into the page, to write cookies,
and more.
|
HttpResponse
|
|
Request
|
Provides access to the current page request, including
the request headers, cookies, client certificate, query string, and so on.
You can use this class to read what the browser has sent.
|
HttpRequest
|
|
Context
|
Provides access to the entire current context (including
the request object). You can use this class to share information between
pages.
|
HttpContext
|
|
Server
|
Exposes utility methods that you can use to transfer
control between pages, get information about the most recent error, encode
and decode HTML text, and more.
|
HttpServerUtility
|
|
Application
|
Provides access to application-wide methods and events
for all sessions. Also provides access to an application-wide cache you can
use to store information
|
HttpApplicationState
|
|
Session
|
Provides information to the current user session. Also
provides access to a session-wide cache you can use to store information,
along with the means to control how the session is managed.
|
HttpSessionState
|
|
Trace
|
Provides a way to display both system and custom trace
diagnostic messages in the HTTP page output.
|
TraceContext
|
No comments:
Post a Comment