|
DOT NET
ANSWERS Intranet:
Intranets
are private, internal systems to help carry out the day-to-day information
processing, management information, and work-flow activities of
organizations. Internet:
Internets
are public information systems. They include public sites that provide news,
information, and entertainment; electronic commerce sites to market and sell
products and services; governmental sites to inform or service the general
public; and educational sites to provide local and remote access to education
and training. Extranet:
Extranets
are business-to-business (B2B) systems that manage electronic data
interchange (EDI) between business enterprises. These systems
facilitate the flow of information between organizations -- between a company
and its suppliers and between the company and its distributors -- to help
coordinate the sequence of purchasing, production, and
distribution. Script Processing: <SCRIPT runat="server"> The
script appearing at the top of the page contains the subroutine named
Display_Output(). The
associated list of arguments contained within parentheses (Src As
Object, Args As EventArgs) are
references to the particular server control which calls the subroutine -- the
button in this case. The Src
(source) parameter is a reference to the source of the subroutine call -- the
button object itself; the Args
(arguments) parameter is a pointer to any data values accompanying the button.
These are standard arguments that must be supplied when a button calls a
subprogram. ASP.NET Page Components Most
ASP.NET pages are arranged in a common structure of common parts. These parts
are illustrated below and described in the following text. <%@ Import Namespace="namespace"
%> Directives A
directive controls how an ASP.NET page is compiled. It is enclosed within
<%@...%>
characters and appears at the top of the Web document. One of the uses of
directives is to import namespaces, collections of software classes
required by the VB.NET code on the page. A common set of namespaces is available
by default and does not need to be explicitly imported. Others, such as those
required for file and database access, need to be imported by coding
directives. One
of the handy directives you will wish to use on all pages assists in
debugging programming errors. This page directive is
It
produces "friendlier" error messages about coding syntax and program execution
errors, pointing you to the line of code in error. The <form>
Control: Web form controls are enclosed within a single <form> tag in the format shown below:
The parameter
runat="server" indicates that form
processing takes place on the server and that enclosed controls are accessible
by server scripts. If you are familiar with conventional form processing, you
notice some missing attributes. The action="url" parameter required for
conventional forms is not needed, and is ignored if coded. The assumption is --
and the requirement is -- that form data are submitted to scripts on the same
page as the form. The POST method coded on conventional forms is also
assumed and needs not be coded on server forms. A data transmission method needs to be specified
only when using a GET method, unlikely when transmitting form data. Also
optional is the name attribute. Form names are
automatically assigned by ASP.NET for its own internal
use. When the basic form
control <form
runat="server"> is coded on the page, a look at
the browser's View Source listing reveals the lines <form name="_ctl0"
method="post" action="page.aspx" id="_ctl0"> ... </form> A name and id value are automatically assigned
to the form; the method is always "post"; and the action is taken to be the
same page containing the form control. It is important to remember that
only one <form
runat="server"> control can appear on a page. It
is often convenient to code the opening tag immediately following the
<body> tag and the closing
tag immediately preceding the </body> tag. In this fashion
the entire page becomes a form within which server controls can be
placed. Input
Controls:
<asp:TextBox id="MyTextField"
runat="server"/> The
prefix asp:
identifies this as a server control, id="MyTextBox"
provides a unique identifier for reference within scripts, and runat="server"
makes the control accessible by server scripts. All
server controls are coded using XHTML notation. That is, all controls
must have opening and closing tags. Output Controls:
There
are several server output controls that serve as targets for script output.
These tutorials discuss the following controls:
Of
course, it is a bit artificial to categorize some controls as purely "input" or
"output" controls. An asp:TextBox
control, for example, serves both purposes. You can enter text for submission to
a script, and it can be the target for script output. So, the classifications
used here have very soft edges and indicate, very generally, the purpose of the
controls. Script Activation
Events:
Scripts
can be run in response to Web page events as well as to user events. A key page
event is the load
event, which occurs when the page is first retrieved by the server in response
to a URL request. At the same time, there
are two conditions under which a page is loaded. On the one hand, it can be
an initial page-load event -- the first time the page is retrieved in
response to a URL request; or, it can be a post-back event -- a
reloading of the same page on form submission. These two page-load events
can be, and often are, programmed separately. <SCRIPT runat="server"> Information Display
Controls: There
are three special controls that have no equivalence among standard form tags.
These controls are unique to ASP.NET and are designed to ease and to automate
the display of complex information. Most often these controls are used to
display tables of data from databases. They are designed so that minimal coding
is required to extract information from those tables and format it for display.
Calling
Functions: Besides
subprograms, functions can be called upon to perform processing. The
difference is that functions return a data value to the calling element.
It is often the case that a function is called from an inline script to supply a
data value for display on the page. A simple example is the
following: <SCRIPT runat="server"> The
inline script calls the Get_Date()
function. The function returns the current date which is substituted for the
function call and is rendered on the page. This exact function is coded on this
page to produce the following output. The current date is:
General Form
Submission: Whenever
a user event triggers a subroutine call, a URL request is made to the server to
retrieve and reload the current page. At the same time, information contained in
the form coded on the page is submitted to the server and is made available to
scripts coded on that page. Usually, that submitted information is processed by
the subprogram identified in the event handler of the control that triggered the
submission. But this need not be the case. A control can trigger a form
submission without identifying a subprogram. For instance, the following
button, <asp:Button Text="Click My"
runat="server"/> makes
a URL request and submits the page for server processing; however, it does not
contain an event handler identifying a subroutine to handle the processing. In
this case, Visual Basic statements contained in the Page_Load
subroutine would have to handle the processing. Although this is not the normal
way to handle ASP.NET processing, it offers the conventional ASP mode of form
submission. Advantages of Server controls:
The
primary functionality provided by these controls is their direct accessibility
by server scripts. A second important feature is that Web forms retain their
values between page postings. The Page
ViewState: This
repopulation of controls with submitted values occurs through the page's
<form name="_ctl0"
method="post" action="page.aspx" id="_ctl0"> The
encrypted value represents the status of the page when it was posted to the
server so that the page can be reconstituted in this format when it is returned
to the browser. Maintaining a Maintaining Variables
on PostBack: Server
controls, by default, take part in a page's
The State
Bag: The State Bag is a data
structure containing names and paired values. A value is placed into the State
Bag by assigning it to a ViewState
name:
ViewState values take
part in the page's Here is a rewrite of
the previous script initializing the counter as ViewState("Counter") when the page is first
loaded, thereby assigning it to the State Bag: <SCRIPT runat="server"> Session
Variables: There is a second
method of retaining the values of variables between page postings. This method
also maintains values between different pages. A user Session
is created by ASP.NET whenever a visitor arrives at any Web page located in your
root application directory. A Session Object maintains identification
information about the visitor and allows ASP.NET to differentiate between
visitors and their browsing status as they navigate the Web
site. Session.SessionID =
"bi1eg345rjr10x45u3nbkb55" a random number that was generated
when you first arrived at this site. Your Session remains alive until 20 minutes
after your last interaction with a page or until you close your browser. A
revisit then generates a new SessionID
number. The Session Object also
serves as a global storage area that scripts can use to maintain data values
between pages. A Session variable is created in the same way as a
ViewState variable, by assigning a value to a name: Session("name") =
"value" TIPS: It
should be remembered that View States only work between postings of the same page. Values are not maintained
when navigating between different pages. Session variables, on the other hand,
remain accessible from all
pages at a Web site, and are an effective way of "passing" data values between
pages. They disappear, though, if the visitor is idle for longer than 20 minutes
or when the browser window is closed. For most applications
THE REQUEST
OBJECT:
Under
ASP.NET, the HttpRequest class provides a Request
object that
contains information about a URL request for a Web page. In general, the
Request
object pertains to Web page input, with a set of properties that provide
information about the URL request received by the page. You can, for example,
determine what type of browser the visitor is using. <SCRIPT runat="server"> <html> Output of the script is
shown below: Properties of your request for this page:Browser Type: IE
The
above values are placed on this page simply by including inline expressions
within the HTML code. For example, the type and major version of the browser you
are using is displayed with the expression <%= Request.Browser.Type
%> The
Response Object:
The Response object, is a part of the HttpResponse software
class. In general, this object provides control over the format and content of
output sent to a Web page. Like the Request object, it
has properties and methods that are activated through scripts. Many of the
features of the Response object pertain to special
programming needs and are not appropriate or necessary for common use. The few
generally useful properties and methods are shown in the following table
accompanied by settings pertaining to your visit to this page.
Probably the most useful of the
methods is Response.Write(), especially when it
comes to debugging scripts. You can write the contents of variables or write
"trace flags" to track progress through a script. They are not part of the
normal processing of the script; they just provide visual indication of reaching
certain checkpoints during processing. Since script blocks are
run on the server prior to sending the page to the browser, output from
Response.Write() statements appears at the top of the
page. You can control where the output
appears on the page by including Response.Write()
statements within in-line scripts. For instance, the following output is
displayed in-place by coding, <%
Response.Write("<b>Write this text string right here.</b>")
%> For Passing Arguments to the
Subroutines: For
Normal Button, the List is Sub sub_Name(Src as Object,
EventArgs as Arguments) However, if more than one button
is calling the same subroutine, the arguments and the Button declaration needs
to like <asp:Button id="MyButton" runat="server" and
, the subroutine needs to be
Sub
MySubroutine (Src As Object, Args As
CommandEventArgs) The
subroutine that is called with OnCommand has
a different signature from one called with OnClick.
Rather than EventArgs, the
list uses CommandEventArgs. It
is through this argument that the passed CommandName and
CommandArgument are
received. The
asp:ImageButton
control displays an image that responds to mouse clicks like a button. The
general format for this control is shown below. <asp:ImageButton id="value"
runat="server" The
URL of the image is given in the ImageURL
attribute and alternate text displayed on a mouseover event is specified in the
AlternateText
attribute. Text alignment around an in-line image is on the Bottom of
the image unless a different ImageAlign
property is specified. By coding the onClick
event handler, the image responds to a mouse click and calls a
subroutine. Like
an asp:Button
control, the asp:ImageButton
supplies OnCommand,
CommandName, and
CommandArgument
properties. These can be employed when more than one image button calls the same
subprogram and the subprogram needs a way to identify the image that was
clicked. In
the case of image maps the signature of the called subroutine must include the
ImageClickEventArgs
argument. Sub GetCoordinates (Source As Object, Args As
ImageClickEventArgs) HyperLink control :
The
asp:HyperLink
control creates a text or graphic link similar to an <a
href> tag.
Its general format is shown below.
The
target page is specified by the NavigateURL
property. The value can be a relative or absolute URL. The link can be displayed
as either text or an image. To display text, set the Text
property; to display an image, set the ImageUrl
property. If both Text and
ImageUrl
properties are set, the ImageUrl
property takes precedence and the Text
property serves as a Tool Tip. If the image is unavailable, the Text
property is displayed. The
assigned name of a
frame or window can be specified within which the linked page is opened by
setting the Target
property; or, the following special references can be
used:
GAC:
A repository of
shared assemblies that are accessible to all .NET applications on a given
machine. Adding your own control assemblies to the GAC is a relatively
straightforward process that requires four steps: 1. Use
the sn.exe command-line utility to create a public key pair for use in
signing your control:
sn.exe -k Blog.snk
One
caveat:
To use custom controls that are installed in the GAC, you must supply the
version, culture, and public key information for the assembly when adding the
@
Register
directive for the control, as shown in the following snippet (which should
appear on a single line): <%@
Register TagPrefix="aspnetian" Namespace="aspnetian"
Assembly="Blog, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=6bd31f35fc9a113b"
%> If you've added your
control to the Visual Studio .NET toolbox, when you use the control from the
toolbox, the correct Migrating ADO.NET
Code:
With the release of the new .NET
Visual Studio (or VS.NET SDK Beta 2), Microsoft has made some fundamental
changes. One area that has been changed is ADO.NET. Namespace The first change that
Microsoft has made is to the namespace that you import. In Beta 1 you would use
the following:
In Beta 2 you now use the
following:
Class
Names Coupled with the
namespace change, the class names have changes as well. The following table
lists some of the Beta 1 class names and their new Beta 2 class
names:
As you can see, the
change has been to replace the leading Class
Changes OleDbCommand In Beta 1, to populate a
In Beta 2, you would now issue the
following:
The fundamental change
is that you no longer have to pass a When invoking the
Another change to the
In Beta 2, the syntax is
now:
Managed
Providers:
When speaking of
data access, it's useful to distinguish between providers of data and consumers
of data. A data provider
encapsulates data and provides access to it in a generic way. The data
itself can be in any form or location. For example, the data may be in a typical
database management system such as SQL Server, or it may be distributed around
the world and accessed via web services. The data provider shields the data
consumer from having to know how to reach the data. In ADO.NET, data providers
are referred to as managed
providers. A data
consumer is an application that uses the services of a data
provider for the purposes of storing, retrieving, and manipulating
data. ADO.NET
is comprised of many classes, but five take center stage: Connection
Represents
a connection to a data source. Command
Represents
a query or a command that is to be executed by a data source.
DataSet
Represents
data. The DataSet can be filled either from a data source (using a DataAdapter
object) or dynamically. DataAdapter
Used
for filling a DataSet from a data source. DataReader
Used
for fast, efficient, forward-only reading of a data source.
With
the exception of DataSet, these five names are not the actual classes used for
accessing data sources. Each managed provider exposes classes specific to that
provider. For example, the SQL Server managed provider exposes the
SqlConnection, SqlCommand, SqlDataAdapter, and SqlDataReader classes. The
DataSet class is used with all managed providers. Any
data-source vendor can write a managed provider to make that data source
available to ADO.NET data consumers. Microsoft has supplied two managed
providers in the .NET Framework: SQL Server and OLE DB. XML WITH
DATASET:
The
DataSet class has several methods for reading and writing data as XML,
including: GetXml
Returns
a string containing an XML representation of the data in the DataSet object.
GetXmlSchema
Returns
a string containing the XSD schema for the XML returned by the GetXml method.
WriteXml
Writes
the XML representation of the data in the DataSet object to a Stream object, a
file, a TextWriter object, or an XmlWriter object. This XML can either include
or omit the corresponding XSD schema. WriteXmlSchema
Writes
the XSD schema for the DataSet to a Stream object, a file, a TextWriter object,
or an XmlWriter object. ReadXml
Reads
the XML written by the WriteXml method. ReadXmlSchema
Reads
the XSD schema written by the WriteXmlSchema method. The
XML created by the WriteXml method contains only data--no schema information.
The ReadXml method is able to infer the schema from the data. To explicitly
write the schema information, use the WriteXmlSchema method. To read the schema
back in, use the ReadXmlSchema method. The
GetXml and GetXmlSchema methods work the same as the WriteXml and WriteXmlSchema
methods, except that each returns its result as a string rather than writing it
to a file. Binding a DataSet to a Windows
Forms DataGrid: DataSet and DataTable
objects can be bound to Windows Forms DataGrid objects to provide an easy way to
view data. This is done by calling a DataGrid object's SetDataBinding method,
passing the object that is to be bound to the grid. The syntax of the
SetDataBinding method is:
dataSource
The
source of the data to show in the grid. This can be any object that exposes the
System.Collections.IList
or System.Data.IListSource
interfaces, which includes the DataTable and DataSet
classes. Each row in the
DataGrid will have a "+" icon. The reason is that the DataGrid object has
detected the relation between the The name of the
relation in the display is a link. Clicking on this link loads the grid with the
child table in the relation. Binding a DataSet to a Web Forms
DataGrid:
VB.NET or
C#:
VB.NET has features
that C# doesn't. For example, the IsDBNull() function is in VB.NET, but not in
C#. VB.NET has exponentiation and can re-allocate arrays using Redim; these
aren't available in C#. C# is case-sensitive for keywords and variables. Most
Visual Basic programmers aren't used to this, and this can cause lost time
unless you're really consistent in your typing. Personally, I like Visual
Basic's use of If. . .End If and Do. . .Loop as opposed to C#'s use of curly
braces. I find it hard to keep track of these braces. Select Case statements are
easier and more compact than in C#. In C#, you have to use the break statement
all the time to break out of the select structure. In Visual Basic, you can use
Case 1 to 50: In C#, you have to code 50 individual case statements for
this. Advantages of
C# One
of the best advantages of C# is the power to support XML documentation. The XML
documentation works a lot like Javadoc—you actually maintain your docs while you
maintain your code. The power to be
unsafe
Much
is made about C#’s type-safety, but if you want to drive without a seatbelt, you
are free to do so. If you really need to use pointers, for example, you can use
the unsafe keyword to mark a block of code. This allows that code to
bypass the Framework’s type-safety checking and means that you can directly
manipulate memory. This makes C# incredibly powerful and is one of the
advantages of C# over VB.NET. I am admittedly a
Visual Basic proponent, but C# does have some advantages. For example, the
ability to have multi-line comments without having to repeat the comment
character is pretty slick. C# can also do pre- and post-incrementing and
decrementing, for example: The first line in the
above code increments the variable intValue by one. The second line decrements
the variable by one. This is a nice shorthand compared to the more lengthy
Visual Basic version of intValue += 1. Another benefit of C#
is that there are currently more sample programs in the beta version than there
are samples in VB.NET. This will likely change in a future release. Although not often used
for business applications, C# lets you have pointers. While pointers can lead to
many problems, there may be times when you need them. In this instance, C# has a
slight advantage over Visual Basic. However, in my programming, I rarely need
pointers. C# has the ability to
use the Unsigned data types defined in the .NET runtime. Again, the need for
this in a business application isn't common, but it is an area where C# has more
access to the .NET runtime engine than VB.NET. WEB FARM:
A server farm is a group of
computers acting as servers and housed together in a single location. A
server farm is sometimes called a server
cluster. A Web server farm can be either (1) a Web site that has more
than one server, or (2) an Internet service provider (ISP) that provides Web hosting services using
multiple servers. In a business network,
a server farm or cluster might perform such services as providing centralized
access control, file access, printer sharing, and backup for workstation users.
The servers may have individual operating systems or a shared operating system
and may also be set up to provide load balancing when there are many server
requests. In a server farm, if one server fails, another can act as backup.
On the Internet, a Web
server farm, or simply Web farm, may refer to a Web site that uses two or
more servers to handle user requests. Typically, serving user requests for the
files (pages) of a Web site can be handled by a single server. However, larger
Web sites may require multiple servers. Web farm is a term that
is also simply used to mean a business that performs Web site hosting on
multiple servers. Some Web farms allow you to put your own server on their site,
a service known as colocation.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||