Overview of ASP.NET ASP.NET consists of several different technologies, including Web Forms, Web Services, server controls, HTML controls, and validation controls, as shown in Figure 6.1. All these technologies, working together, make it possible (and some might even say "easy") to create robust, maintainable, scalable Web applications. You''''ll use Web Forms to lay out the user interface of your applications, using server controls as the basis for user interaction. (If you''''re importing an existing HTML or ASP page, you might use the other set of controls, HTML controls, which don''''t provide as rich an experience for users, nor are they as easy to work with, programmatically, as server controls. For new pages, you''''ll most likely want to use the new server controls.) In addition, the set of validation controls (actually, just a subset of the total set of server controls) makes it easy for you to validate user input, either on the client side, on the server side, or both. Web Services provide a platform for creating distributed component-based applications, and ASP.NET makes it easy to create and consume Web Services.
Figure 6.1. ASP.NET includes many different technologies.
You will be introduced to each of these different technologies in this chapter, and you''''ll explore them in further detail in subsequent chapters.
Web Forms Web Forms are the heart and soul of ASP.NET. Web Forms are the user interface (UI) elements that give your Web application its look and feel. Web Forms are similar to the .NET Framework''''s Windows Forms (or even VB6''''s forms) in that they provide properties, methods, and events for the controls that are placed on them. However, these UI elements render themselves in the appropriate markup language required by the request (in this case, HTML). If you use Visual Studio .NET, you also get the familiar drag-and-drop interface for creating the interface for your Web application.
When you create Web applications using Visual Studio .NET, Web Forms are made up of two files: the visual portion (the ASPX file) and the code behind the page, which resides in a separate class file. (Microsoft refers to this separate file containing code as the page''''s code-behind file. We''''re not kidding.) If you create Web applications outside Visual Studio .NET (yes, it''''s possible, although it''''s not terribly productive), you can place the user interface and the code in the same file. The layout information will still be separated from the code, but both parts can exist within the same file.
Web Forms and ASP.NET were created to overcome some of the limitations of ASP. The new strengths of ASP.NET include the following:
Separation of the HTML interface from application logic
A rich set of server-side controls that can detect the browser and send out appropriate markup language, such as HTML
Data binding capabilities of the new server-side .NET controls, which means less code to write
An event-based programming model that is familiar to Visual Basic pro- grammers
Compiled code and support for multiple languages, as opposed to ASP, which supported only interpreted VBScript or JScript
Allowing third parties to create controls that provide additional functionality
XML Web Services XML Web Services make up the second portion of ASP.NET''''s functionality. Developers have, for several years, required some means of executing methods across the Internet梩hat is, some way to programmatically request information or an action and then retrieve the results. A Web Service is an object that can be called remotely (normally using HTTP) that solves this need.
ASP.NET makes it easy for you to create Web Services, and any application that understands how to work with XML data can consume the service.
NOTE
When you use an XML Web Service, under the covers, ASP.NET is using the Simple Object Access Protocol (SOAP) standard for its messaging protocol. This standard indicates how a Web Service consumer should package up its method requests, and it specifies how a Web Service should send back its results. As long as both sides (service and consumer) follow the SOAP specification, any Web Service should be able to interact with any Web Service consumer.
These Web Services may be written in any .NET language, or any language running on any platform, as long as the Web Services follow the SOAP specification. Web Services can also be called from any .NET language or any language that has the capability to process SOAP envelopes and call HTTP interfaces.
A Web Service created in .NET always returns an XML string. When you use the .NET Framework, you will not need to get your hands "dirty" handling any of the XML manually; any return value you send back will automatically be wrapped into an XML string for you. That is, the .NET Framework handles all the details, packaging and unpackaging the XML necessary for the Web Service to do its job. All you need to do is create the code that performs the work, passing in parameters as necessary, and returning the correct value. The .NET Framework will manage converting XML packets into your parameters and converting the return value back into an XML string for the Web Service consumer.
Figure 6.2 shows, in a simplified fashion, how a client application might consume an XML Web Service. Things don''''t have to work this way, but if you take all the default options in Visual Studio .NET, this is the path your Web Service data will take.
Figure 6.2. A Web Service client receives and sends information to and from the Web Service.
When you create a Web Service in .NET, you create a class that has public methods. Each public method may be exposed as a method simply by you adding a procedure attribute to the method as you create the procedure. (By adding the <WebMethod()> attribute, you''''re telling the .NET Framework that it must expose the procedure as a Web Service method.) The .NET compiler takes care of creating the necessary files that allow another process to call this Web Service across an HTTP interface. Figure 6.3 demonstrates, in a simplified manner, how the translation occurs.
Figure 6.3. NET hides the SOAP implementation.
When you compile a Web Service created in .NET, it will automatically generate a number of files for you. When a Web Service consumer application (either created in .NET, or not) needs to determine information about the Web Service and its available methods, it will use these files:
It''''s important to realize that nothing about XML Web Services requires any Microsoft technology. In this book, we''''ll focus on creating and consuming XML Web Services in the context of Microsoft''''s tools and servers, but none of these is actually required. If you want to create a Web Service hosted on a Linux server, using Apache, you''''re welcome to do so. If you want to consume a Web Service using a Lotus Notes application, that works fine, too. That''''s the beauty of embracing an existing standard. All we can say is that it''''s a lot easier creating and consuming Web Services using Visual Studio .NET than in any other tool we''''ve seen.
.VSDISCO. A Visual Studio Discovery file. This file gives a list of Web Services available on a particular Web site.
.WSDL. A Web Services Description Language file. This file describes the method name(s) available for the selected Web Service. For each method, there is also a list of parameters and a description of the return value.
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
