技术ASP NET中英文对照外文翻译文献

合集下载

ASP NET 5外文文献和翻译

ASP NET 5外文文献和翻译

5 : Introducing the 5 PreviewDaniel Roth | Special connect(); issue 2014 shipped as part of the Microsoft .NET Framework 1.0, released in 2002 along with Visual Studio 2002. It was an evolution of Active Server Pages (ASP) that brought object-oriented design, the .NET Base Class Libraries (BCLs), better performance and much more. was designed to make it easy for developers used to writing desktop applications to build Web applications with Web Forms. As the Web evolved, new frameworks were added to : MVC in 2008, Web Pages in 2010, and Web API and SignalR in 2012. Each of these new frameworks built on top of the base from 1.0.With 5, is being reimagined just like ASP was reimagined to in 2002. This reimagining brings many new features:•Full side-by-side support: 5 applications can now be installed on a machine without affecting any other applications on the machine.•Cross-platform support: 5 runs and is supported on Windows, Mac and Linux. •Cloud-ready: Features such as diagnostics, session state, cache and configuration are designed to work locally and in the cloud.•Faster development: The build step is removed; just save source files and refresh the browser and compilation happens automatically.•MVC, Web Pages and Web API: These are all merged together, simplifying the number of concepts.•Flexible hosting: You can now host your entire 5 application on IIS or in your own process.Getting Started with 5 PreviewIn this article, I’ll give an overview of the new experiences the development team—of which I’m a part—has created for 5 and Visual Studio 2015 Preview. For general help with building and running 5 applications, visit /vNext, where you can findstep-by-step guides and additional documentation. In addition, we also post updates regularlyto /b/webdev. To get started, download and install Visual Studio 2015 Preview. Overview of the 5 Runtime 5 has been rebuilt from the ground up to support building modern Web applications and services. It’s open source, cross-platform and works both on-premises and in the cloud. 5 is currently in Preview and under active development on GitHub (/aspnet). I’llprovide an overview of what’s new in the 5 Preview along with pointers to where you can learn more.Flexible, Cross-Platform Runtime At its foundation, 5 is based on a new flexible runtime host. It provides the flexibility to run your application on one of three different runtimes: 1.Microsoft .NET Framework: You can run your 5 applications on the existing .NETFramework. This gives you the greatest level of compatibility for existing binaries. Core: A refactored version of the .NET Framework that ships as a set of NuGet packagesthat you can include with your app. With .NET Core, you get support for true side-by-side versioning and the freedom to use the latest .NET features on your existing infrastructure. Note that not all APIs are available yet on .NET Core, and existing binaries generally need to be recompiled to run on .NET Core.3.Mono: The Mono CLR enables you to develop and run 5 apps on a Mac or Linuxdevice. For mor e information, see the blog post, “Develop vNext Applications on a Mac,” at bit.ly/1AdChNZ.Regardless of which CLR is used, 5 leverages a common infrastructure for hosting the CLR and provides various services to the application. This infrastructure is called the K Runtime Environment (KRE). While it’s somewhat of a mystery where the “K” in KRE comes from (a tribute to the Katana Project? K for Krazy Kool?), the KRE provides everything you need to host and run your app.A New HTTP Pipeline 5 introduces a new modular HTTP request pipeline that can be hosted on the server of your choice. You can host your 5 applications on IIS, on any Open Web Interface for .NET (OWIN)-based server or in your own process. Because you get to pick exactly what middleware runs in the pipeline for your app, you can run with as little or as much functionality as you need and take advantage of bare-metal performance. 5 includes middleware for security, request routing, diagnostics and custom middleware of your own design. For example, here’s a simple middleware implementation for handling of theX-HTTP-Method-Override header:e((context, next) =>{var value = context.Request.Headers["X-HTTP-Method-Override"];if (!string.IsNullOrEmpty(value)){context.Request.Method = value;}return next();}); 5 uses an HTTP pipeline model similar in many ways to the OWIN-based model introduced with Project Katana, but with several notable improvements. Like Katana, 5 supports OWIN, but simplifies development by including a lightweight and easy-to-use HttpContext abstraction.There’s a Package for That Package managers have changed the way developers think about installing, updating and managing dependencies. In 5, all your dependencies are represented as packages. NuGet packages are the unit of reference. 5 makes it easy to build, install and use packages from package feeds and also to work with community packages on the node package manager (NPM) and Bower. 5 introduces a simple JSON format (project.json) for managing NuGet package dependencies and for providing cross-platform build infrastructure. An example project.json file is shown in Figure 1 (a more detailed explanation of each of the supported properties can be found on GitHub atbit.ly/1AIOhK3).Figure 1 An Example project.json File{"webroot": "wwwroot","version": "1.0.0-*","exclude": ["wwwroot"],"packExclude": ["**.kproj","**.user","**.vspscc"],"dependencies": {"Microsoft.AspNet.Server.IIS": "1.0.0-beta1","Microsoft.AspNet.Diagnostics": "1.0.0-beta1"},"frameworks" : {"aspnet50" : { },"aspnetcore50" : { }}}The Best of C# Design-time and run-time compilation for 5 applications are handled using the managed .NET Compiler Platform (code-named “Roslyn”). This means you get to take advantage of the latest C# language features while leveraging in-memory compilation to avoid unnecessary disk I/O. 5 projects are based on a new project system that dynamicallycompiles your application on-the-fly as you’re coding so you can avoid the interruption of a specific build step. This gives you the power of .NET and C# with the agility and feel of an interpreted language.Built-in Dependency Injection All 5 applications have access to a common dependency injection (DI) service that helps simplify composition and testing. All the frameworks built on 5 (MVC, Web API, SignalR and Identity) leverage this common DI service. While 5 comes with a minimalistic Inversion of Control (IoC) container to bootstrap the system, you can easily replace that built-in IoC container with your container of choice.Familiar Web Frameworks 5 includes frameworks for building Web apps and services such as MVC, Web API, Web Pages (coming in a future release), SignalR and Identity. Each of these frameworks has been ported to work on the new HTTP request pipeline and has been built to support running on the .NET Framework, .NET Core or cross-platform.Today, the existing implementations of MVC, Web API and Web Pages share many concepts and duplicate abstractions, but share very little in the way of actual implementation. As part of porting these frameworks to 5, Microsoft decided to take a fresh look at combining these frameworks into a single unified Web stack. MVC 6 takes the best of MVC, Web API and Web Pages and combines it into a single framework for building Web UI and Web APIs. This means from a single controller you can just as easily render a view as return formatted data based on content negotiation.In addition to unification, MVC 6 introduces a host of new features:•Built-in DI support•Ability to create controllers from any class—no base class required•Action-based request dispatching•View Components—a simple replacement for child actions•Routing improvements, including simplified attribute routing•Async views with flush points•Ability to inject servers and helpers into views using @inject•ViewStart inheritance•Tag helpersYou can find more information and samples at /aspnet/mvc.Web Forms isn’t available on 5, but is still fully supported on the .NET Framework. There are a number of important new features coming to Web Forms in the upcoming version of the .NET Framework, including support for HTTP 2.0, async model binding and a Roslyn-based CodeDom provider. We’re also working on various features reminiscent of Web Forms in MVC 6, such as tag helpers and other Razor improvements.Entity FrameworkData is a key part of many applications and Entity Framework (EF) is a popular data access choice for developers. While EF7 isn’t specific to , this new version of EF plays an integral role in 5.EF7 Enables New Platforms EF is widely used in client and server applications that target thefull .NET Framework. A key focus of EF7 is to enable EF to be used on the remaining platforms where .NET development is common. These include 5, Windows Store and Windows Phone applications, as well as .NET-based Mac and Linux applications.For Windows Phone and Windows Store applications, the initial goal is to provide local data access using EF. SQLite is the most common database of choice on devices and will be the primary store for local data on devices with EF7. The full provider model will be available, though, so other data stores can be supported also.EF7 Enables New Data Stores While parts of EF are clearly tied to relational data stores, muchof the functionality that EF provides is also applicable to many non-relational data stores. Examples of such functionality include change tracking, LINQ and unit of work. EF7 will enable providers that target non-relational data stores, such as Microsoft Azure Table Storage.We’re explicitly not trying to build an abstraction layer that hides the type of data store you’re targeting. The common patterns/components that apply to most data stores will be handled by the core framework. Things specific to particular types of data stores will be available asprovider-specific extensions. For example, the concept of a model builder that allows you to configure your model will be part of the core framework. However, the ability to configure things such as cascade delete on a foreign key constraint will be included as extensions in the relational database provider.EF7 Is Lightweight and Extensible EF7 will be a lightweight and extensible version that pulls forward some commonly used features. In add ition, we’ll be able to include some commonly requested features that would’ve been difficult to implement in the EF6 code base, but which can be included from the start in EF7.The team will be keeping the same patterns and concepts you’re used to in EF, except where there’s a compelling reason to change something. You’ll see the same DbContext/DbSet-based API, but it will be built over building block components that are easy to replace or extend as needed—the same pattern used for some of the isolated components added in recent EF releases.More Information on EF7For more information on EF7, visit the “What Is EF7 All About” GitHub page at aka.ms/AboutEF7. The page includes design information, links to blog posts and instructions for trying out EF7. Command-Line ToolsOne of the core 5 tenets was to provide a command-line experience before we built the tooling experience. This means that almost all tasks you need to do with an 5 application can be done from the command line. The main reason for this is to ensure a viable option for using 5 without Visual Studio for those using Mac or Linux machines.KVM The first tool you need to get the full command-line experience for 5 is the K Version Manager (KVM). The KVM command-line tool can download new versions of the KRE and let you switch between them. KRE contains other command-line tools that you might use. How KVM is implemented, and how to get it, depends on the OS. You can download and install KVM for your platform by running the appropriate command from /aspnet/Home.Once you have KVM, you should be able to open a command prompt and run the kvm command. If you run “kvm list,” you’ll see the list of all KRE versions on your machine, as shown in Figure 2.Figure 2 Running “kvm list” at the Command Line to Get a List of KRE Versions on Your MachineIf there are no entries in your list, there are no versions of KRE in your user profile. To fix this, you can run the command “kvm upgrade.” This command will determine the latest version of the KRE available, download it and modify your PATH environment variable so you can use the other command-line tools in the KRE itself.You can use “kvm install <version/latest>” to install a particular version without making it the default. Use the –r switch to indicate whether you want the .NET Core or .NET Frameworkversion of the KRE and the –x86 and –amd64 switches to download the 32- or 64-bit flavors of the KRE. The runtime and bitness switches can be supplied to either install or upgrade.Once you’ve called “kvm upgrade,” you’ll be able to use the K and KPM commands. K can be used to run applications, while KPM is used to manage packages.How does KVM work? At its heart, KVM is just a convenient way to manipulate your PATH. When you use “KVM use <version>,” all it does is change your PATH to the bin folder of the KRE version you specified is on your PATH. By default the KRE is installed by copying and extracting the KRE .zip file into %USERPROFILE%\.kre\packages, so when you type “KVM use 1.0.0-beta1,” KVM will make surethat %USERPROFILE%\.kre\packages\KRE-CLR-x86.1.0.0-beta1\bin is on your PATH.KPM The next tool you’ll want to use is the KRE Package Manager (KPM). The KPM performs two main functions, with a few lesser features:1.You can run “kpm restore” in a folder with a project.json file to download all the packages your application needs.2.It provides the pack command, “kpm pack,” which will take your application and generate aself-contained, runnable image of your application. Here, image means a folder structure that’s designed to be copied to the server and run. It will include all the packages your application requires, as well as, optionally, the KRE on which you want to run the application.The restore command can be run in a folder that contains a project.json file. It will examine thefile and, using NuGet.config, connect to a NuGet feed and attempt to download all the packages your application needs. By default, it will install these packagesin %USERPROFILE%\.kpm\packages so only one copy of any given package needs to be on your dev machine, even if used in multiple projects.Packing your application—by running “kpm pack”—will generate a folder containing everything your app needs to run, including packages, source files and your Web root. You can even optionally include the KRE, although by default it’s assumed the KRE is already on the server.K Command The K command actually runs an 5 application from the command line. The K command is included in the KRE, the same as KPM, and is the entry point to running an application on top of the KRE.The main way to use the K command is to run one of the commands inside your project.json file. Commands are specified by name in the project.json file under the commands property. By default,the 5 Starter Web template includes a “web” command in project.json that hosts your app and listens on port 5000. To run th is command, simply run “k web.”Visual Studio Updates for 5One of the original goals of 5 was to have a great experience for teams in which members use different tools. For example, you can have team members using Windows and Visual Studio working with others who are using Sublime Text on a Mac (see options forcross-platform .NET development tools ). To achieve this, we had to take a step back and rethink Visual Studio support. In previous versions of Visual Studio, the project system assumed that most development was performed in Visual Studio. Visual Studio didn’t work well when other tools were involved to create files or modify the project. For example, in the .csproj file, Visual Studio maintained a list of files that made up the project. If you used a tool to create a new file for your project, you’d then have to edit the .csproj file for it to be included.In Visual Studio 2015, when you create a new 5 project, you get a new experience. You can still develop, debug and run your project as usual, but in addition to the standard features that you’ve come to know in projects, some new features are unique to 5. You now have the freedom to develop using the p latform and tooling of your choice. I’ll discuss some of those features.Support for All Files in the Folder In 5, all files under the project directory are automatically included in the project. You can exclude files from compile or publish in the project.json file. For more info on how to exclude files in project.json, see the GitHub pageat bit.ly/1AIOhK3. After the project is loaded, Visual Studio starts a file watcher and updates Solution Explorer to reflect the changes. Because Solution Explorer is always watching the files under the project directory, we’ve changed the location where generated files will be stored. Instead of storing generated files under the project (bin\ and obj\), we now place generated files by default in a folder named artifacts next to the solution file.Just Edit, Save and Refresh the Browser In existing applications, when you change server-side logic (such as your MVC controller code, or a filter) then you need to rebuild and redeploy the application to see the changes reflected in the browser. Microsoft wanted the Web developer workflow to feel as lightweight and agile as when working with interpreted platforms (such as Node.js or Ruby), while still letting you leverage the power of .NET. In 5 projects, when you edit and save your C# code, a file watcher detects the change and restarts the application. The application is rebuilt in memory, so you can see the results of the change in the browser in near-real time. Not e that this workflow is only supported when you aren’t debugging so as to avoid interrupting your debugging session.Web Publishing In Visual Studio 2015, Microsoft developers are working on a new publish process for 5 projects. In the Preview release, 5 publishing supports publishing to Azure Websites and to the file system (for example, local/network folder). When publishing to Azure Websites, you can select the desired build configuration and KRE version. Later releases will expand this to support a broader set of targets.Migrating to 5Moving existing Web applications to 5 involves both creating a new 5 project for your existing application and then migrating your code and dependencies to run on the new framework. Creating a new 5 project for your application is relatively simple. First, add a project.json file in your project folder. Initially, the project.json file only needs to include an empty JSON object (for example, {}). Next, use File | Open Project to open the project.json file in Visual Studio 2015 Preview. After opening the project.json file, Visual Studio will create an 5 project with a .kproj file and automatically include in the project all the files and directories it finds next to the project.json file. You should see your project files in your new 5 project in the Solution Explorer. You have now created an 5 project for your existing Web application!Migrating your code and dependencies so your new 5 project builds and runs correctly is a more involved process. You need to update your project.json with your top-level package dependencies, framework assembly references and project references. You need to migrate your code to use the new HTTP abstractions, the new middleware model and the new versions of the Web frameworks. You need to move to new infrastructure for handling concerns such as configuration, logging and DI. Porting your application to run on .NET Core requires dealing with additional platform changes and limitations. This is more than can be covered in this article, but we’re working hard to provide complete migration guidance in a future article. While the investment to move to 5 might be significant, Microsoft believes the benefits of providing an open source, community-driven, cross-platform and cloud-ready framework are worth the additional effort.翻译:是微软.NET Framework 1.0运作的一部分,与Visual Studio 2002版本一同发布在2002年。

计算机专业ASPNET外文翻译

计算机专业ASPNET外文翻译

Extreme 1.1Web Deployment ProjectsWhen ASP was first released, Web programming was more difficult because you needed IIS to serve your ASP pages. Later, 2.0 and Visual Studio® 2005 made everything easier by introducing the Web site model of development. Instead of creating a new project inside Visual Studio, the Web site model lets you point to a directory and start writing pages and code. Furthermore, you can quickly test your site with the built-in Development Server, which hosts in a local process and obviates the need to install IIS to begin developing. The beauty of the Web site model is that you can develop your Web application without thinking about packaging and deployment. Need another class? Add a .cs file to the App_Code directory and start writing. Want to store localizable strings in a resource file? Add a .resx file to the App_GlobalResources directory and type in the strings. Everything just works; you don't have to think about the compilation and deployment aspect at all.When you are ready to deploy, you have several options. The simplest choice is to copy your files to a live server and let everything be compiled on-demand (as it was in your test environment). The second option is to use the aspnet_compiler.exe utility and precompile the application into a binary release, which leaves you nothing but a collection of assemblies, static content, and configuration files to push to the server. The third option is to again use aspnet_compiler.exe, but to create an updateable binary deployment where your .as*x files remain intact (and modifiable) and all of your code files are compiled into binary assemblies.This seems to cover every possible scenario, leaving the developer to focus simply on writing the Web application, with packaging and deployment decisions to be made later when the application is actually deployed. There was a fair amount of backlash against this model, however, especially from developers who were used to their Web projects being real projects, specified in real project files, that let you inject pre-and post-build functions, exclude files from the build process, move between debug and release builds with a command-line switch, and so on. In response, Microsoft quickly introduced the Web Application Project or WAP, initially released as an add-in to Visual Studio 2005, and now included in Visual Studio 2005 Service available for download from /vstudio/support/vs2005sp1.WAP provides an alternative to the Web site model that is much closer to the Visual Studio .NET 2005 Web Project model. The new WAP model compiles all of the source code files during the build process and generates a single assembly in the local /bin directory for deployment. WAP also makes it much easier to incrementally adopt the new partial class codebehind modelintroduced in 2.0 because you can now open a Visual Studio .NET 2003 project and only your .sln and .csproj (or .vbproj) files will be modified during the conversion. You can then convert each file and its codebehind class to the new partial class model independently of any other file in the project (by right-clicking on the file in the Solution Explorer and selecting Convert to Web Application), or just leave them using the old model. This is in contrast to converting a Visual Studio .NET 2003 Web project to the Web site model, which converts all files at once and does not support incremental adoption.Finally, there is a new project type called Web Deployment Projects (the main topic of this column), which introduces myriad additional deployment options for both Web site projects and Web Application Projects. Web Deployment Projects fill the remaining holes in the deployment options for both Web site apps and Web Application Projects and make it possible to implement practically any deployment scenario in a simple and extensible way. To understand exactly what this new project type adds, let's first review what we had before Web Deployment Projects were available.When you build an application using the Web site model, you have the option of precompiling the site for deployment. You can access the precompilation utility through the Build | Publish menu in Visual Studio 2005 or directly through the command-line utility aspnet_compiler.exe. Figure 1 shows the interface to this tool exposed by Visual Studio.The first decision you have to make when using the publish utility is whether you want your .as*x files to be updatable once deployed (use the "Allow this precompiled site to be updatable" option of -u switch in the aspnet_compiler.exe command-line utility). This decision hinges on whether you want to be able to make minor changes to your pages once deployed without having to go through the entire deployment process again. You may, in fact, want to explicitly disallow any modifications to the deployed pages and require that all modifications go through the standard deployment (and hopefully testing) process, in which case publishing the site as not updatable is the proper choice.When a site is published as not updatable, it is possible to completely remove all .as*x files and publish only binary assemblies (plus configuration files and static content). However, without the physical files in place, it is impossible for to tell which classes to use for which endpoint requests. For example, if a request comes into your application for Page1.aspx and you have used non-updatable binary deployment, there very well may not be any Page1.aspx file on disk, and there is nothing in the existing configuration files to indicate which class in the collection of assemblies deployed to the /bin directory should actually be the handler for this request. To remedy this, the compilation process will also generate a collection of .compiled filesthat contain endpoint-to-type mapping and file dependency information in a simple XML format, and these files must be published along with the binary assemblies in the /bin directory of the deployed site. As an example, if you did have a page named Page1.aspx in your application, the aspnet_compiler.exe utility would generate a file named piled (with the hash code varying) that contained the following XML:<?xml version="1.0" encoding="utf-8"?><preserve resultType="3"virtualPath="/SampleWebSite/Page1.aspx"hash="8a8da6c5a" filehash="42c4a74221152888"flags="110000" assembly="App_Web_aq9bt8mj"type="ASP.page1_aspx"><filedeps><filedep name="/SampleWebSite/Page1.aspx" /><filedep name="/SampleWebSite/Page1.aspx.cs" /></filedeps></preserve>The other major decision you have to make when publishing a Web site with this utility is the granularity of the packaging of the generated assemblies. You can either create a separate assembly for each directory in your site or create a separate assembly for each compilable file in your site (.aspx, .ascx, .asax, and so on.) by checking the Use fixed naming and single page assemblies (or -fixednames in the aspnet_compiler.exe command-line utility). This decision is not as obvious as you might think, as each option has its own potential issues. If you elect to not use the -fixednames option, then every time you publish your application a completely new set of assemblies will be generated, with completely different names from the ones published earlier. This means that deployment is trickier because you must take care to delete all of the previously published assemblies on the live server before deploying the new assemblies or you'll generate redundant class definition errors on the next request. Using the -fixednames option will resolve this problem as each file will correspond to a distinctly named assembly that will not change from one compilation to the next. If you have a large site, however, generating a separate assembly for each page, control, and Master Page can easily mean managing the publication of hundreds of assemblies. It is this problem of assembly granularity in deployment that Web Deployment Projects solve in a much more satisfying way, as you will see.You can also introduce assembly signing into the compilation process to create strong-named, versioned assemblies, suitable for deployment in the Global Assembly Cache(GAC) if needed. You can mark the generated assemblies with the assembly-level attribute AllowPartiallyTrustedCallers using the -aptca option, which would be necessary if you did deploy any assemblies to the GAC and were running at a low or medium level of trust. (Keep in mind that this attribute should only be applied to assemblies that have been shown not to expose any security vulnerabilities, as using it with a vulnerability could expose a luring attack.) One other detail about publishing your site is that if you do elect to use Web Application Projects instead of the Web site model, the Build | Publish dialog box will look quite different, as shown in Figure 2. Web Application Projects assume that you want to publish the application as updatable .as*x files and precompiled source files (the same model it uses in development), so the binary-only deployment options are not available. This utility is really closer in nature to the Copy Web site utility available with Web sites than it is to the Publish Web Site utility since it involves copying files produced by the standard build process.Technically you are not restricted from using binary-only (non-updatable) deployment, even if you are using Web Application Projects. If you think about it, the output of the build of a WAP is a valid Web site, which you can then pass through the aspnet_compiler.exe utility to generate create a binary deployment. You just can't invoke it from the Visual Studio 2005 interface which, fortunately, Web Deployment Projects rectify.So what's missing from the existing compilation and deployment options presented so far? Primarily two things: the ability to control the naming of assemblies, especially for deployment purposes, and the ability to consolidate all of the output assemblies into a single assembly for simplified deployment. Web Deployment Projects solve both of these problems. Perhaps even more significantly, however, they also tie up a lot of loose ends in the deployment story that existed with Web site applications and Web Application Projects.At their core, Web Deployment Projects (available for download at /aa336619.aspx) represent just another type of project you add to your solution. Like all Visual Studio project files, Web deployment projects are MSBuild scripts that can be compiled directly in the IDE or run from the command line. Instead of specifying a collection of source code files to compile, however, Web Deployment Projects contain build commands to compile and package Web sites (or Web Application Projects). This means that they will invoke the aspnet_compiler.exe utility (among others) to create a deployment of a particular Web application. Web Deployment Projects are shipped as a Visual Studio add-in package that includes an easy-to-use menu item for injecting new projects and a complete set of property pages to control all of the available settings. To add one to an existing application, right-click on an existing Web site (or Web Application Project) and select the Add Web Deployment Project itemas shown in Figure 3. This will add a new .wdproj file containing an MSBuild script to your solution, which will generate a deployment of the application you created it from.Once the Web Deployment Project is part of your solution, you can access the property pages of the project file to control exactly what the project does for you, as shown in Figure 4. The default setting for a new deployment project is to deploy the application in updatable mode, with all the .as*x files intact, and the source files compiled into a single assembly deployed in the top-level /bin directory. These deployment projects work the same regardless of whether the source application is using the Web site model or the Web Application Project model, which means that you can now select either development model without impacting your deployment options. One of the most significant features of Web Deployment Projects is the ability to configure the deployment to be all binary (not updatable) in the form of a single assembly, the name of which you can choose. Using this model of deployment means that you can update your entire site merely by pushing a single assembly to the /bin directory of your live site, and not concern yourself with deleting existing assemblies prior to deploying or dealing with a partially deployed site causing errors. It is still necessary to deploy the .compiled files for the endpoint mappings, but these files only change when you add, delete, or move pages in your site.Web Deployment Projects provide flexibility in deployment and let you make packaging and deployment decisions independently of how you actually built your Web applications. This independence between development and deployment was partially achieved in the original release of 2.0 with the aspnet_compiler.exe utility, but never fully realized because of the constraints imposed when performing the deployment. With Web Deployment Projects, the separation between development and deployment is now complete, and your decision about how to build your applications will no longer impact your deployment choices.Merging AssembliesMuch of what Web Deployment Projects provide is just a repackaging of existing utilities exposed via MSBuild tasks and a new interface, but there are also a couple of completely new features included. The most intriguing is the ability to merge assemblies.When you install Web Deployment Projects, you will find an executable called aspnet_merge.exe in the installation directory. This executable is capable of taking the multi-assembly output of a precompiled site and merging the assemblies into one. This is the utility that is incorporated into your build script if you select the merge option in a Web Deployment Project. As an example of what is possible with this utility, consider the output of a precompiled Web site, run without the updatable switch, shown in Figure 5. The source application for this output contained two subdirectories, a top-level global.asax file, a classdefined in App_Code, and a user control. The end result of the compilation is five different assemblies and a collection of .compiled files. If you run the aspnet_merge.exe utility on this directory with the -o switch to request a single assembly output, shown at the bottom of Figure 5, the result is a much more manageable single assembly named whatever you specify.Although the aspnet_merge.exe utility and the corresponding MSBuild task that ship with Web Deployment Projects are new, the underlying technology for merging assemblies has actually been around since the Microsoft® .NET Framework 1.1 in the form of a utility made available from Microsoft Research called ILMerge, the latest version of which is available for download from /~mbarnett/ILMerge.aspx. This utility is directly incorporated into aspnet_merge.exe and does all the heavy lifting involved with merging assemblies. If you think about it, the merging of assemblies is a rather complicated task. You need to take into consideration signing, versioning, and other assembly-level attributes, embedded resources, and XML documentation, as well as manage the details of clashing type names, and so on. The ILMerge utility manages all of these details for you, with switches to control various decisions about the process. It also gives you the ability to transform .exe assemblies into .dll assemblies for packaging purposes. As an example, suppose you have three assemblies: a.dll, b.dll, and c.exe which you would like to merge into a single library assembly. As long as there were no conflicts in typenames, the following command line would generate a new library, d.dll with all of the types defined in a.dll, b.dll, and c.exe:ilmerge.exe /t:library /ndebug /out:d.dll a.dll b.dll c.exePluggable Configuration FilesThe other completely new feature that comes with Web Deployment Projects is the ability to create pluggable configuration files. It is a common problem when deploying Web applications to find a way to manage the differences in your configuration files between development and deployment. For example, you may have a local test database to run your site, have another database used by a staging server, and yet another used by the live server. If you are storing your connection strings in web.config (typically in the connectionStrings section), then you need some way of modifying those strings when the application is pushed out to a staging server or to a production machine. Web Deployment Projects offer a clean solution to this problem with a new MSBuild task called ReplaceConfigSections.This task allows you to specify independent files that store the contents of a particular configuration section independently based on solution configurations. For example, you might create a debugconnectionstrings.config file to store the debug version of our connectionStrings configuration section that looked like this:<connectionStrings><add connectionString="server=localhost;database=sales;trusted_connection=yes" name="sales_dsn"/> </connectionStrings>Similarly, you would then create separate files for each of the solution configurations defined (release, stage, and so on) and populate them with the desired connection strings for their respective deployment environments. For the release configuration, you might name the file releaseconnectionstrings.config and populate it as follows:<connectionStrings><add connectionString="server=livedbserver;database=sales;trusted_connection=yes"name="sales_dsn"/></connectionStrings>Next, you would configure the MSBuild script added by Web Deployment Projects to describe which configuration sections in the main web.config file should be replaced, and the source files that will supply the content for the replacement. You could modify the script by hand, but there is a nice interface exposed through the property pages of the build script in Visual Studio that will do it for you, as Figure 6 shows. In this case, you are setting the properties for the debug solution configuration, so check the Enable Web.config file section replacement option and specify the section to be replaced along with the file with the contents to replace it: You would use this same dialog page to set the configuration replacement for the Release solution configuration (and any others we had defined) with the corresponding files.When you then run the build script, the ReplaceConfigSections task extracts the contents from any associated config files and replaces the contents of the corresponding configuration section, creating a new web.config file that is pushed to the deployment directory. This configuration file replacement feature means that you can maintain configuration differences between deployment environments in a manageable way with text files that can be versioned under source control, and you don't have to resort to referring to that sticky note reminding you to change the connection string when you deploy. It should be emphasized that this feature works with any section of the configuration file, even custom sections, so if you have differences in other configuration sections (for example, appSettings) you can easily specify those differences with this build task as well.Creating Reusable User ControlsThere is an interesting side application of Web deployment projects that solves a problem that has plagued developers for years-how to create reusable user controls to share across applications. User controls are fundamentally just composite custom controls whose child controls are laid out in an .ascx file. The ability to use the designer for laying out controls and adding handlers is a huge benefit for most developers since it feels almost identical to building a page, except that the resulting .ascx file can be included as a control in any page. The disadvantage has always been that you need the physical .ascx file in the application's directory to actually use it. Techniques for making .ascx controls shareable across applications are available, but they usually involve chores like creating shared virtual directories between applications or harvesting temporary assemblies generated by at request time, and they've never been satisfactory.The introduction of the aspnet_compiler.exe utility in version 2.0 brought us much closer to a decent solution. With the compiler, you can create a Web site consisting of only user controls and publish the site in non-updateable mode using the compiler to generate reusable assemblies. Once you have the resulting assembly (or assemblies), you can then deploy to any Web application and reference the user control just as you would a custom control (not by using the src attribute as you would for .ascx files). The only disadvantage to this technique is that you either have to accept the randomly named assembly produced by the compilation process or select the fixednames option in the compiler to generate a fixed named assembly for each Master Page in the site (not a single assembly for the entire collection).Web Deployment Projects provide the final step to create truly reusable user control assemblies. You can take the same Web site consisting exclusively of user controls and add a Web Deployment Project to create a single output assembly with the name of your choice. It's even straightforward to create a signed assembly to deploy to the GAC for sharing controls across multiple applications without redeploying the assembly in each /bin directory.ConclusionThe release of Web Deployment Projects completes the set of tools for deploying applications in a very satisfying way. It is now possible to deploy your applications in any manner ranging from all source to all binary, with complete control over the generation, packaging, and naming of the binary assemblies. In addition, Web Deployment Projects provide a solution for replacing sections of your configuration files based on your target build, and they solve the problem of distributing reusable user controls. Anyone who is building and deploying applications will undoubtedly find some aspect of Web Deployment Projects compelling enough to begin using them today.2.1 Client-Side Web Service Calls with AJAX ExtensionsSince its inception, has fundamentally been a server-side technology. There were certainly places where would generate client-side JavaScript, most notably in the validation controls and more recently with the Web Part infrastructure, but it was rarely more than a simple translation of server-side properties into client-side behavior-you as the developer didn't have to think about interacting with the client until you received the next POST request. Developers needing to build more interactive pages with client-side JavaScript and DHTML were left to do it on their own, with some help from the 2.0 script callbacks feature. This has changed completely in the last year.At the Microsoft Professional Developer's Conference in September 2005, Microsoft unveiled a new add-on to , code-named "Atlas," which was focused entirely on leveraging client-side JavaScript, DHTML, and the XMLHttpRequest object. The goal was to aid developers in creating more interactive AJAX-enabled Web applications. This framework, which has since been renamed with the official titles of Microsoft® AJAX Library and the 2.0 AJAX Extensions, provides a number of compelling features ranging from client-side data binding to DHTML animations and behaviors to sophisticated interception of client POST backs using an UpdatePanel. Underlying many of these features is the ability to retrieve data from the server asynchronously in a form that is easy to parse and interact with from client-side JavaScript calls. The topic for this month's column is this new and incredibly useful ability to call server-side Web services from client-side JavaScript in an 2.0 AJAX Extensions-enabled page.Calling Web Services with AJAXIf you have ever consumed a Web service in the Microsoft .NET Framework, either by creating a proxy using the wsel.exe utility or by using the Add Web Reference feature of Visual Studio®, you are accustomed to working with .NET types to call Web services. In fact, invoking a Web service method through a .NET proxy is exactly like calling methods on any other class. The proxy takes care of preparing the XML based on the parameters you pass, and it carefully translates the XML response it receives into the .NET type specified by the proxy method. The ease with which developers can use the .NET Framework to consume Web service endpoints is incredibly enabling, and is one of the pillars that make service-oriented applications feasible today.The 2.0 AJAX Extensions enable this exact same experience of seamless proxy generation for Web services for client-side JavaScript that will run in the browser. You can author an .asmx file hosted on your server and make calls to methods on that service through a client-side JavaScript class. For example, Figure 1 shows a simple .asmx service that implements a faux stock quote retrieval (with random data).In addition to the standard .asmx Web service attributes, this service is adorned with the ScriptService attribute that makes it available to JavaScript clients as well. If this .asmx file is deployed in an AJAX-Enabled Web application, you can invoke methods of the service from JavaScript by adding a ServiceReference to the ScriptManager control in your .aspx file (this control is added automatically to your default.aspx page when you create a Web site in Visual Studio using the AJAX-enabled Web site template):<asp:ScriptManager ID="_scriptManager" runat="server"><Services><asp:ServiceReference Path="StockQuoteService.asmx" /></Services></asp:ScriptManager>Now from any client-side JavaScript routine, you can use the MsdnMagazine.StockQuoteService class to call any methods on the service. Because the underlying mechanism for invocation is intrinsically asynchronous, there are no synchronous methods available. Instead, each proxy method takes one extra parameter (beyond the standard input parameters)- a reference to another client-side JavaScript function that will be called asynchronously when the method completes. The example page shown in Figure 2 uses client-side JavaScript to print the result of calling the stock quote Web service to a label (span) on the page.If something goes wrong with a client-side Web service call, you definitely want to let the client know, so it's usually wise to pass in another method that can be invoked if an error, abort, or timeout occurs. For example, you might change the OnLookup method shown previously as follows, and add an additional OnError method to display any problems:function OnLookup(){var stb = document.getElementById("_symbolTextBox");MsdnMagazine.StockQuoteService.GetStockQuote(stb.value, OnLookupComplete, OnError);}function OnError(result){alert("Error: " + result.get_message());}This way if the Web service call fails, you will notify the client with an alert box. You can also include a userContext parameter with any Web service calls made from the client, which is an arbitrary string passed in as the last parameter to the Web method, and it will be propagated to both the success and failure methods as an additional parameter. In this case, it might make sense to pass the actual symbol of the stock requested as the userContext so you can display it in the OnLookupComplete method:function OnLookup(){var stb = document.getElementById("_symbolTextBox");MsdnMagazine.StockQuoteService.GetStockQuote(stb.value, OnLookupComplete, OnError, stb.value);}function OnLookupComplete(result, userContext){// userContext contains symbol passed into methodvar res = document.getElementById("_resultLabel");res.innerHTML = userContext + " : <b>" + result + "</b>";}If you find that you're making many different calls to a Web service, and that you re-use the same error and/or complete methods for each call, you can also set the default error and succeeded callback method globally. This avoids having to specify the pair of callback methods each time you make a call (although you can choose to override the globally defined methods on a per-method basis). Here is a sample of the OnLookup method that sets the default succeeded and failed callback methods globally instead of on a per-call basis.// Set default callbacks for stock quote serviceMsdnMagazine.StockQuoteService.set_defaultSucceededCallback(OnLookupComplete);MsdnMagazine.StockQuoteService.set_defaultFailedCallback(OnError);function OnLookup(){MsdnMagazine.StockQuoteService.GetStockQuote(stb.value);}。

ASP NET 概述中英文对照外文翻译文献

ASP NET 概述中英文对照外文翻译文献

中英文资料对照外文翻译 概述 是一个统一的 Web 开发模型,它包括您使用尽可能少的代码生成企业级 Web 应用程序所必需的各种服务。

作为 .NET Framework 的一部分提供。

当您编写 应用程序的代码时,可以访问 .NET Framework 中的类。

您可以使用与公共语言运行库 (CLR) 兼容的任何语言来编写应用程序的代码,这些语言包括 Microsoft Visual Basic、C#、JScript .NET 和 J#。

使用这些语言,可以开发利用公共语言运行库、类型安全、继承等方面的优点的 应用程序。

包括:∙页和控件框架∙ 编译器∙安全基础结构∙状态管理功能∙应用程序配置∙运行状况监视和性能功能∙调试支持∙XML Web services 框架∙可扩展的宿主环境和应用程序生命周期管理∙可扩展的设计器环境 页和控件框架是一种编程框架,它在 Web 服务器上运行,可以动态地生成和呈现 网页。

可以从任何浏览器或客户端设备请求 网页, 会向请求浏览器呈现标记(例如 HTML)。

通常,您可以对多个浏览器使用相同的页,因为 会为发出请求的浏览器呈现适当的标记。

但是,您可以针对诸如 Microsoft Internet Explorer 6 的特定浏览器设计 网页,并利用该浏览器的功能。

支持基于 Web 的设备(如移动电话、手持型计算机和个人数字助理 (PDA))的移动控件。

网页是完全面向对象的。

在 网页中,可以使用属性、方法和事件来处理 HTML 元素。

页框架为响应在服务器上运行的代码中的客户端事件提供统一的模型,从而使您不必考虑基于 Web 的应用程序中固有的客户端和服务器隔离的实现细节。

该框架还会在页处理生命周期中自动维护页及该页上控件的状态。

使用 页和控件框架还可以将常用的 UI 功能封装成易于使用且可重用的控件。

控件只需编写一次,即可用于许多页并集成到 网页中。

英文文献及中文翻译_ASP.NET概述ASP.NETOverview

英文文献及中文翻译_ASP.NET概述ASP.NETOverview

英文文献及中文翻译 Overview is a unified Web development model that includes the services necessary for you to build enterprise-class Web applications with a minimum of is part of the .NET Framework, and when coding applications you have access to classes in the .NET Framework.You can code your applications in any language compatible with the common language runtime (CLR), including Microsoft Visual Basic and C#. These languages enable you to develop applications that benefit from the common language runtime, type safety, inheritance, and so on.If you want to try , you can install Visual Web Developer Express using the Microsoft Web Platform Installer, which is a free tool that makes it simple to download, install, and service components of the Microsoft Web Platform.These components include Visual Web Developer Express, Internet Information Services (IIS), SQL Server Express, and the .NET Framework. All of these are tools that you use to create Web applications. You can also use the Microsoft Web Platform Installer to install open-source and PHP Web applications.Visual Web DeveloperVisual Web Developer is a full-featured development environment for creating Web applications. Visual Web Developer provides an ideal environment in which to build Web sites and then publish them to a hosting site. Using the development tools in Visual Web Developer, you can develop Web pages on your own computer. Visual Web Developer includes a local Web server that provides all the features you need to test and debug Web pages, without requiring Internet Information Services (IIS) to be installed.Visual Web Developer provides an ideal environment in which to build Web sitesand then publish them to a hosting site. Using the development tools in Visual Web Developer, you can develop Web pages on your own computer. Visual Web Developer includes a local Web server that provides all the features you need to test and debug Web pages, without requiring Internet Information Services (IIS) to be installed.When your site is ready, you can publish it to the host computer using the built-in Copy Web tool, which transfers your files when you are ready to share them with others. Alternatively, you can precompile and deploy a Web site by using the Build Web Site command. The Build Web Sitecommand runs the compiler over the entire Web site (not just the code files) and produces a Web site layout that you can deploy to a production server.Finally, you can take advantage of the built-in support for File Transfer Protocol (FTP).Using the FTP capabilities of Visual Web Developer, you can connect directly to the host computer and then create and edit files on the server. Web Sites and Web Application ProjectsUsing Visual Studio tools, you can create different types of projects, which includes Web sites, Web applications, Web services, and AJAX server controls.There is a difference between Web site projects and Web application projects. Some features work only with Web application projects, such as MVC and certain tools for automating Web deployment. Other features, such as Dynamic Data, work with both Web sites and Web application projects.Page and Controls FrameworkThe page and controls framework is a programming framework that runs on a Web server to dynamically produce and render Web pages. Web pages can be requested from any browser or client device, and renders markup (such as HTML) to the requesting browser. As a rule, you can use the samepage for multiple browsers, because renders the appropriate markup for the browser making the request. However, you can design your Web page to target a specific browser and take advantage of the features of that browser. Web pages are completely object-oriented. Within Web pages you can work with HTML elements using properties, methods, and events. The page framework removes the implementation details of the separation of client and server inherent in Web-based applications by presenting a unified model for responding to client events in code that runs at the server. The framework also automatically maintains the state of a page and the controls on that page during the page processing life cycle.The page and controls framework also enables you to encapsulate common UI functionality in easy-to-use, reusable controls. Controls are written once, can be used in many pages, and are integrated into the Web page that they are placed in during rendering.The page and controls framework also provides features to control the overall look and feel of your Web site via themes and skins. You can define themes and skins and then apply them at a page level or at a control level.In addition to themes, you can define master pages that you use to create a consistent layout for the pages in your application. A single master page defines the layout and standard behavior that you want for all the pages (or a group of pages) in your application. You can then create individual content pages that contain the page-specific content you want to display. When users request the content pages, they merge with the master page to produce output that combines the layout of the master page with the content from the content page. The page framework also enables you to define the pattern for URLs that will be used in your site. This helps with search engine optimization (SEO) and makes URLs more user-friendly.The page and control framework is designed to generate HTML thatconforms to accessibility guidelines. CompilerAll code is compiled, which enables strong typing, performance optimizations, and early binding, among other benefits. Once the code has been compiled, the common language runtime further compiles code to native code, providing improved performance. includes a compiler that will compile all your application components including pages and controls into an assembly that the hosting environment can then use to service user requests.Security InfrastructureIn addition to the security features of .NET, provides an advanced security infrastructure for authenticating and authorizing user access as well as performing other security-related tasks. You can authenticate users using Windows authentication supplied by IIS, or you can manage authentication using your own user database using forms authentication and membership. Additionally, you can manage the authorization to the capabilities and information of your Web application using Windows groups or your own custom role database using roles. You can easily remove, add to, or replace these schemes depending upon the needs of your application. always runs with a particular Windows identity so you can secure your application using Windows capabilities such as NTFS Access Control Lists (ACLs),database permissions, and so on.State-Management Facilities provides intrinsic state management functionality that enables you to store information between page requests, such as customer information or the contents of a shopping cart. You can save and manage application-specific, session-specific, page-specific, user-specific, and developer-defined information. This information can beindependent of any controls on the page. offers distributed state facilities, which enable you to manage state information across multiple instances of the same application on one computer or on several computers. 概述是一个统一的Web开发模型,它包括您使用尽可能少的代码生成企业级Web应用程序所必需的各种服务。

ASP NET 2.0网页和Web控件-外文翻译

ASP NET 2.0网页和Web控件-外文翻译

外文翻译毕业设计题目:基于的物业管理系统开发原文1: 2.0 Web Pagesand Web Controls译文1: 2.0 网页和Web控件原文2:The Role of Global.asax File 译文2:Global.asax文件的作用原文1 2.0 Web Pages and Web Controls U ntil now, all of the example applications in this text have focused on console-based and Windows Forms front ends. In this chapter and the next, you’ll explore how the .NET platform facilitates the construction of browser-based presentation layers. To begin, you’ll quickly review a number of key web-centric concepts (HTTP, HTML, client-side, and server-side script) and the role of the web server (including the development server, WebDev.WebServer.exe).With this web primer out of the way, the remainder of this chapter concentrates on the composition of (including the enhanced code-behind model) and how to work with web controls. As you will see, 2.0 provides a number of new web controls, a new “master page”model, and various customization techniques.The Role of HTTPWeb applications are very different animals from traditional desktop applications (to say the least).The first obvious difference is that a production-level web application will always involve at least two networked machines (of course, during development it is entirely possible to have a single machine play the role of both client and server). Given this fact, the machines in question must agree upon a particular wire protocol to determine how to send and receive data. The wire protocol that connects the computers in question is the Hypertext Transfer Protocol (HTTP).When a client machine launches a web browser (such as Netscape Navigator, Mozilla Firefox,or Microsoft Internet Explorer), an HTTP request is made to access a particular resource (such as an *.aspx or *.htm file) on the remote server machine. HTTP is a text-based protocol that is built upon a standard request/response paradigm. For example, if you navigate to www. , the browser software leverages a web technology termed Domain Name Service (DNS) that converts the registered URL into a four-part, 32-bit numerical value (aka an IP address). At this point, the browser opens a socket connection (typically via port 80) and sends the HTTP request for the default page at the website.Once the hosting web server receives the incoming HTTP request, the specified resource may contain logic that scrapes out any client-supplied input values (such as values within a text box) in order to format a proper HTTP response. Web programmers may leverage any number of technologies (CGI, ASP, , Java servlets, etc.) to dynamically generate the content to be emitted into theHTTP response. At this point, the client-side browser renders the HTML emitted from the web server.Another aspect of web development that is markedly different from traditional desktop programming is the fact that HTTP is an essentially stateless wire protocol. As soon as the web server emits a response to the client, everything about the previous interaction is forgotten. Therefore, as a web developer, it is up to you take specific steps to “remember” information (such as items in a shopping cart) about the clients who are currently logged on to your site. As you will see in the next chapter, provides numerous ways to handle state, many of which are commonplace to any web platform (session variables, cookies, and application variables) as well as some new techniques (view state, control state, and the cache).Understanding Web Applications and Web ServersA web application can be understood as a collection of files (*.htm, *.asp, *.aspx, image files, etc.) and related components (such as a .NET code library) stored within a particular set of directories on a given web server. As shown in Chapter 24, web applications have a specific life cycle and provide numerous events (such as initial startup or final shutdown) that you can hook into.A web server is a software product in charge of hosting your web applications, and it typically provides a number of related services such as integrated security, File Transfer Protocol (FTP) support, mail exchange services, and so forth. Internet Information Server (IIS) is Microsoft’s enterprise-level web server product, and as you would guess, it has intrinsic support for classic ASP as well as web applications.When you build web applications, you will often need to interact with IIS. Be aware, however, that IIS is not automatically selected when you install the Windows Server 2003 or Windows XP Professional Edition (you can’t install IIS on the Home editions of Windows). Therefore, depend ing on the configuration of your development machine, you may be required to manually install IIS before proceeding through this chapter. To do so, simply access the Add/Remove Program applet from the Control Panel folder and select Add/Remove Windows Components.Working with IIS Virtual DirectoriesA single IIS installation is able to host numerous web applications, each of which resides in a virtual directory. Each virtual directory is mapped to a physical directory on the local hard drive. Therefore,if you create a new virtual directory named CarsRUs, the outside world can navigate to this site using a URL such as (assuming your site’s IP address has been registeredwith the world at large). Under the hood, the virtual directory maps to a physical root directory such as C:\inetpub\wwwroot\AspNetCarsSite, which contains the content of the web application.When you create web applications using Visual Studio 2005, you have the option of generating a new virtual directory for the current website. However, you are also able to manually create a virtual directory by hand. For the sake of illustration, assume you wish to create a simple web application named Cars. The first step is to create a new folder on your machine to hold the collection of files that constitute this new site (e.g., C:\CodeTests\CarsWebSite).Next, you need to create a new virtual directory to host the Cars site. Simply right-click the Default Web Site node of IIS and select New ➤Virtual Directory from the context menu. This menu selection launches an integrated wizard. Skip past the welcome screen and give your website a name (Cars). Next, you are asked to specify the physical folder on your hard drive that contains the various files and images that represent this site (in this case, C:\CodeTests\CarsWebSite).The final step of the wizard prompts you for some basic traits about your new virtual directory (such as read/write access to the files it contains, the ability to view these files from a web browser, the ability to launch executables [e.g., CGI applications], etc.). For this example, the default selections are just fine (be aware that you can always modify your selections after running this tool using variousright-click Property dialog boxes integrated within IIS).译文1作者:迪诺·弗雷国籍:美国出处: 2.0 and Data-Bound Controls 2.0网页和Web控件到现在为止,本书的示例应用程序主要集中在控制台和基于Windows窗体前端。

asp.net外文文献+翻译

asp.net外文文献+翻译

技术1.构建 页面 和结构 是微软.NET framework整体的一部分, 它包含一组大量的编程用的类,满足各种编程需要。

在下列的二个部分中, 你如何学会 很适合的放在.NET framework, 和学会能在你的 页面中使用语言。

.NET类库假想你是微软。

假想你必须支持大量的编程语言-比如Visual Basic 、C# 和C++. 这些编程语言的很多功能具有重叠性。

举例来说,对于每一种语言,你必须包括存取文件系统、与数据库协同工作和操作字符串的方法。

此外,这些语言包含相似的编程构造。

每种语言,举例来说,都能够使用循环语句和条件语句。

即使用Visual Basic 写的条件语句的语法不与用C++ 写的不一样,程序的功能也是相同的。

最后,大多数的编程语言有相似的数据变量类型。

以大多数的语言,你有设定字符串类型和整型数据类型的方法。

举例来说,整型数据最大值和最小值可能依赖语言的种类,但是基本的数据类型是相同的。

对于多种语言来说维持这一功能需要很大的工作量。

为什么继续再创轮子? 对所有的语言创建这种功能一次,然后把这个功能用在每一种语言中岂不是更容易。

.NET类库不完全是那样。

它含有大量的满足编程需要的类。

举例来说,.NET类库包含处理数据库访问的类和文件协同工作,操作文本和生成图像。

除此之外,它包含更多特殊的类用在正则表达式和处理Web协议。

.NET framework,此外包含支持所有的基本变量数据类型的类,比如:字符串、整型、字节型、字符型和数组。

最重要地, 写这一本书的目的, .NET类库包含构建的 页面的类。

然而你需要了解当你构建.NET页面的时候能够访问.NET framework 的任意类。

理解命名空间正如你猜测的, .NET framework是庞大的。

它包含数以千计的类(超过3,400) 。

幸运地,类不是简单的堆在一起。

.NET framework的类被组织成有层次结构的命名空间。

【毕业设计】文献翻译 原文译文(探究ASP-NET-MVC请求的生命周期)

【毕业设计】文献翻译 原文译文(探究ASP-NET-MVC请求的生命周期)

MVC In-Depth: The Life of an MVC Request The purpose of this blog entry is to describe, in painful detail, each step in the life of an MVC request from birth to death. I want to understand everything that happens when you type a URL in a browser and hit the enter key when requesting a page from an MVC website.Why do I care? There are two reasons. First, one of the promises of MVC is that it will b e a very extensible framework. For example, you’ll be able to plug in different view engines to control how your website content is rendered. You also will be able to manipulate how controllers get generated and assigned to particular requests. I want to walk through the steps involved in an MVC page request because I want to discover any and all of these extensibility points.Second, I’m interested in Test-Driven Development. In order to write unit tests for controllers, I need to understand all of the controller dependencies. When writing my tests, I need to mock certain objects using a mocking framework such as Typemock Isolator or Rhino Mocks. If I don’t understand the page request lifecycle, I won’t be able to effectively mock it.Two WarningsB ut first, two warnings.Here's the first warning: I’m writing this blog entry a week after the MVC Preview 2 was publicly released. The MVC framework is still very much in Beta. Therefore, anything that I describe in this blog entry might be outdated and, therefore, wrong in a couple of months. So, if you are reading this blog entry after May 2008, don’t believe everything you read.Second, this blog entry is not meant as an overview of MVC. I describe the lifecycle of an MVC request in excruciating and difficult to read detail. Okay, you have been warned.Overview of the Lifecycle StepsThere are five main steps that happen when you make a request from an MVC website:Step 1 : The RouteTable is CreatedWhen you request a page from a normal application, there is a page on disk that corresponds to each page request. For example, if you request a page named SomePage.aspx then there better be a page named SomePage.aspx sitting on your web server. If not, you receive an error.Technically, an page represents a class. And, not just any class. An page is a handler. In other words, an page implements the IHttpHandler interface and has a ProcessRequest() method that gets called when you request the page. The ProcessRequest() method is responsible for generating the content that gets sent back to the browser.So, the way that a normal application works is simple and intuitive. You request a page, the page request corresponds to a page on disk, the page executes its ProcessRequest() method and content gets sent back to the browser.An MVC application does not work like this. When you request a page from an MVC application, there is no page on disk that corresponds tothe request. Instead, the request is routed to a special class called a controller. The controller is responsible for generating the content that gets sent back to the browser. When you write a normal application, you build a bunch of pages. There is always a one-to-one mapping between URLs and pages. Corresponding to each page request, there better be a page.When you build an MVC application, in contrast, you build a bunch of controllers. The advantage of using controllers is that you can have a many-to-one mapping between URLs and pages. For example, all of the following URLs can be mapped to the same controller:The single controller mapped to these URLs can display product information for the right product by extracting the product Id from the URL. The controller approach is more flexible than the classic approach. The controller approach also results in more readable and intuitive URLs.So, how does a particular page request get routed to a particular controller? An MVC application has something called a Route Table. The Route Table maps particular URLs to particular controllers.An application has one and only one Route Table. This Route Table is setup in the Global.asax file. Listing 1 contains the default Global.asax file that you get when you create a new MVC Web Application project by using Visual Studio.An application’s Route Table is represented by the static RouteTable.Routes property. This property represents a collection of Route objects. In the Global.asax file in Listing 1, two Route objects are added to the Route Table when the application first starts (The Application_Start() method is called only once when the very first page is requested from a website).A Route object is responsible for mapping URLs to handlers. In Listing 1, two Route objects are created. Both Route objects map URLs to the MvcRouteHandler. The first Route maps any URL that follows the pattern {controller}/{action}/{id} to the MvcRouteHandler. The second Route maps the particular URL Default.aspx to the MvcRouteHandler.By the way, this new routing infrastructure can be used independently of an MVC application. The Global.asax file maps URLs to the MvcRouteHandler. However, you have the option of routing URLs to a different type of handler. The routing infrastructure described in this section is contained in a distinct assembly named System.Web.Routing.dll. You can use the routing without using the MVC.Step 2 : The UrlRoutingModule Intercepts the RequestWhenever you make a request against an MVC application, the request is intercepted by the UrlRoutingModule HTTP Module. An HTTP Module is a special type of class that participates in each and every page request. For example, classic includes a FormsAuthenticationModule HTTP Module that is used to implement page access security using Forms Authentication.When the UrlRoutingModule intercepts a request, the first thing the module does is to wrap up the current HttpContext in an HttpContextWrapper2 object. The HttpContextWrapper2 class, unlike the normal HttpContext class, derives from theHttpContextBase class. Creating a wrapper for HttpContext makes it easier to mock the class when you are using a Mock Object Framework such as Typemock Isolator or Rhino Mocks.Next, the module passes the wrapped HttpContext to the RouteTable that was setup in the previous step. The HttpContext includes the URL, form parameters, query string parameters, and cookies associated with the current request. If a match can be made between the current request and one of the Route objects in the Route Table, then a RouteData object is returned.If the UrlRoutingModule successfully retrieves a RouteData object then the module next creates a RouteContext object that represents the current HttpContext and RouteData. The module then instantiates a new HttpHandler based on the RouteTable and passes the RouteContext to the new handler’s constructor.In the case of an MVC application, the handler returned from the RouteTable will always be an MvcHandler. Whenever the UrlRoutingModule can match the current request against a Route in the Route Table, an MvcHandler is instantiated with the current RouteContext.The last step that the module performs is setting the MvcHandler as the current HTTP Handler. An application calls the ProcessRequest() method automatically on the current HTTP Handler which leads us to the next step.Step 3 : The MvcHandler ExecutesIn the previous step, an MvcHandler that represents a particular RouteContext was set as the current HTTP Handler. An application always fires off a certain series of events including Start, BeginRequest, PostResolveRequestCache, PostMapRequestHandler, PreRequestHandlerExecute, and EndRequest events (there are a lot of application events – for a complete list, lookup the HttpApplication class in the Microsoft Visual Studio 2008 Documentation).Everything described in the previous section happens during the PostResolveRequestCache and PostMapRequestHandler events. The ProcessRequest() method is called on the current HTTP Handler right after the PreRequestHandlerExecute event.When ProcessRequest() is called on the MvcHandler object created in the previous section, a new controller is created. The controller is created from a ControllerFactory. This is an extensibility point since you can create your own ControllerFactory. The default ControllerFactory is named, appropriately enough, DefaultControllerFactory.The RequestContext and the name of the controller are passed to the ControllerFactory.CreateController() method to get a particular controller. Next, a ControllerContext object is constructed from the RequestContext and the controller. Finally, the Execute() method is called on the controller class. The ControllerContext is passed to the Execute() method when the Execute() method is called.Step 4 : The Controller ExecutesThe Execute() method starts by creating the TempData object (called the Flash object in the Ruby on Rails world). The TempData can be used to store temporary data that must be used with the very next request (TempData is like Session State with no long-term memory).Next, the Execute() method builds a list of parameters from the request. These parameters, extracted from the request parameters, will act as method parameters. The parameters will be passed to whatever controller method gets executed.The Execute() method finds a method of the controller to execute by using reflection on the controller class (.NET reflection and not navel gazing reflection). The controller class is something that you wrote. So the Execute() method finds one of the methods that you wrote for your controller class and executes it. The Execute() method will not execute any controller methods that are decorated with the NonAction attribute.At this point in the lifecycle, we’ve entered your application code.Step 5 : The RenderView Method is CalledNormally, your controller methods end with a call to either the RenderView() or RedirectToAction() method. The RenderView() method is responsible for rendering a view (a page) to the browser.When you call a controller’s RenderView() method, the call is delegated to the current ViewEngine’s RenderView() method. The ViewEngine is another extensibility point. The default ViewEngine is the WebFormViewEngine. However, you can use another ViewEngine such as the NHaml ViewEngine.The WebFormViewEngine.RenderView() method uses a class named the ViewLocator class to find the view. Next, it uses a BuildManager to create an instance of a ViewPage class from its path. Next, if the page has a master page, the location of the master page is set (again, using the ViewLocator class). If the page has ViewData, the ViewData is set. Finally, the RenderView() method is called on the ViewPage.The ViewPage class derives from the base System.Web.UI.Page class. This is the same class that is used for pages in classic . The final action that RenderView() method performs is to call ProcessRequest() on the page class. Calling ProcessRequest() generates content from the view in the same way that content is generated from a normal page.SummaryThe goal of this blog entry was to describe the entire life of an MVC request from birth to death. I examined the five steps involved in processing an MVC request: Creating the RouteTable, Intercepting the request with the UrlRoutingModule, Generating a Controller, Executing an Action, and Rendering a View.探究 MVC: MVC请求的生命周期本书详细描述了 MVC请求从开始到结束的整个过程,当你在浏览器上输入URL地址并且在网站请求页面敲击回车时,这个过程就产生了。

ASP和net技术及数据库管理外文原文+中文翻译

ASP和net技术及数据库管理外文原文+中文翻译
第 1 页 共 12 页
服务器上运行。将程序在服务器端首次运行时进行编译,比 ASP 即时解释程序速 度上要快很多.而且是可以用任何与 . net 兼容的语言(包括 Visual Basic . net、 C# 和 JScript . net.)创作应用程序。另外,任何 ASP. net 应用程序都可以使用 整个 . net Framework。开发人员可以方便地获得这些技术的优点,其中包括托管 的 公 共 语 言 运 行 库 环 境 、 类 型 安 全 、 继 承 等 等 。 ASP. net 可 以 无 缝 地 与 WYSIWYG HTML 编辑器和其他编程工具(包括 Microsoft Visual Studio . net) 一起工作。这不仅使得 Web 开发更加方便,而且还能提供这些工具必须提供的 所有优点, 包括开发人员可以用来将服务器控件拖放到 Web 页的 GUI 和完全集 成的调试支持。 当创建 ASP. net 应用程序时,开发人员可以使用 Web 窗体或 XML Web services,或以他们认为合适的任何方式进行组合。每个功能都能得到 同一结构的支持,使您能够使用身份验证方案,缓存经常使用的数据,或者对应 用程序的配置进行自定义. 如果你从来没有开发过网站程序,那么这不适合你,你 应该至少掌握一些 HTML 语言和简单的 Web 开发术语(不过我相信如果有兴趣的 话是可以很快的掌握的)。你不需要先前的 ASP 开发经验(当然有经验更好) ,但 是你必须了解交互式 Web 程序开发的概念, 包含窗体, 脚本, 和数据接口的概念, 如果你具备了这些条件的话,那么你就可以在 的世界开始展翅高飞了。 不仅仅是 Active Server Page (ASP) 的下一个版本,而且是一种建立 在通用语言上的程序构架,能被用于一台 Web 服务器来建立强大的 Web 应用程 序。 提供许多比现在的 Web 开发模式强大的优势。 ASP. net 运行的架构分为几个阶段: 在 IIS 与 Web 服务器中的消息流动阶段。 在 ASP. net 网页中的消息分 派。 在 ASP. net 网页中的消息处理。 ASP. net 的原始设计构想,就是要让开发人员能够像 VB 开发工具那样,可 以使用事件驱动式程序开发模式 (Event-Driven Programming Model) 的方法来 开发网页与应用程序,若要以 ASP 技术来做到这件事的话,用必须要使用大量的 辅助信息,像是查询字符串或是窗体字段数据来识别与判断对象的来源、事件流 向以及调用的函数等等,需要撰写的代码量相当的多,但 ASP. net 很巧妙利用窗 体字段和 JavaScript 脚本把事件的传递模型隐藏起来了。 在 ASP. net 运行的时候, 经常会有网页的来回动作 (round-trip), 在 ASP. net 中称为 PostBack,在传统的 ASP 技术上,判断网页的来回是需要由开发人员自 行撰写,到了 ASP. net 时,开发人员可以用 Page.IsPostBack 机能来判断是否 为第一次运行 (当 发现 HTTP POST 要求的数据是空值时), 它可以保 证 ASP. net 的控件事件只会运行一次,但是它有个缺点(基于 HTTP POST 本 身的缺陷) ,就是若用户使用浏览器的刷新功能 (按 F5 或刷新的按钮) 刷新网页 时,最后一次运行的事件会再被运行一次,若要避免这个状况,必须要强迫浏览 器清空高速缓存才可以。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

中英文对照翻译 Technique1. Building Pages and the .NET Framework is part of Microsoft's overall .NET framework, which contains a vast set of programming classes designed to satisfy any conceivable programming need. In the following two sections, you learn how fits within the .NET framework, and you learn about the languages you can use in your pages.The .NET Framework Class LibraryImagine that you are Microsoft. Imagine that you have to support multiple programming languages—such as Visual Basic, JScript, and C++. A great deal of the functionality of these programming languages overlaps. For example, for each language, you would have to include methods for accessing the file system, working with databases, and manipulating strings.Furthermore, these languages contain similar programming constructs. Every language, for example, can represent loops and conditionals. Even though the syntax of a conditional written in Visual Basic differs from the syntax of a conditional written in C++, the programming function is the same.Finally, most programming languages have similar variable data types. In most languages, you have some means of representing strings and integers, for example. The maximum and minimum size of an integer might depend on the language, but the basic data type is the same.Maintaining all this functionality for multiple languages requires a lot of work. Why keep reinventing the wheel? Wouldn't it be easier to create all this functionality once and use it for every language?The .NET Framework Class Library does exactly that. It consists of a vast set of classes designed to satisfy any conceivable programming need. For example,the .NET framework contains classes for handling database access, working with the file system, manipulating text, and generating graphics. In addition, it contains more specialized classes for performing tasks such as working with regular expressions and handling network protocols.The .NET framework, furthermore, contains classes that represent all the basic variable data types such as strings, integers, bytes, characters, and arrays.Most importantly, for purposes of this book, the .NET Framework Class Library contains classes for building pages. You need to understand, however, that you can access any of the .NET framework classes when you are building your pages.Understanding NamespacesAs you might guess, the .NET framework is huge. It contains thousands of classes (over 3,400). Fortunately, the classes are not simply jumbled together. The classes of the .NET framework are organized into a hierarchy of namespaces.ASP Classic NoteIn previous versions of Active Server Pages, you had access to only five standard classes (the Response, Request, Session, Application, and Server objects). , in contrast, provides you with access to over 3,400 classes!A namespace is a logical grouping of classes. For example, all the classes that relate to working with the file system are gathered together into the System.IO namespace.The namespaces are organized into a hierarchy (a logical tree). At the root of the tree is the System namespace. This namespace contains all the classes for the base data types, such as strings and arrays. It also contains classes for working with random numbers and dates and times.You can uniquely identify any class in the .NET framework by using the full namespace of the class. For example, to uniquely refer to the class that represents a file system file (the File class), you would use the following:System.IO.FileSystem.IO refers to the namespace, and File refers to the particular class.NOTEYou can view all the namespaces of the standard classes in the .NET Framework Class Library by viewing the Reference Documentation for the .NET Framework.Standard NamespacesThe classes contained in a select number of namespaces are available in your pages by default. (You must explicitly import other namespaces.) These default namespaces contain classes that you use most often in your applications:System— Contains all the base data types and other useful classes such as those related to generating random numbers and working with dates and times.System.Collections— Contains classes for working with standard collection types such as hash tables, and array lists.System.Collections.Specialized— Contains classes that represent specializedcollections such as linked lists and string collections.System.Configuration— Contains classes for working with configuration files (Web.config files).System.Text— Contains classes for encoding, decoding, and manipulating the contents of strings.System.Text.RegularExpressions— Contains classes for performing regularexpression match and replace operations.System.Web— Contains the basic classes for working with the World Wide Web, including classes for representing browser requests and server responses.System.Web.Caching— Contains classes used for caching the content of pages and classes for performing custom caching operations.System.Web.Security— Contains classes for implementing authentication and authorization such as Forms and Passport authentication.System.Web.SessionState— Contains classes for implementing session state.System.Web.UI— Contains the basic classes used in building the user interface of pages.System.Web.UI.HTMLControls— Contains the classes for the HTML controls.System.Web.UI.WebControls— Contains the classes for the Web controls..NET Framework-Compatible LanguagesFor purposes of this book, you will write the application logic for your pages using Visual Basic as your programming language. It is the default language for pages. Although you stick to Visual Basic in this book, you also need to understand that you can create pages by using any language that supports the .NET Common Language Runtime. Out of the box, this includes C#, , and the Managed Extensions to C++.NOTEThe CD included with this book contains C# versions of all the code samples.Dozens of other languages created by companies other than Microsoft have been developed to work with the .NET framework. Some examples of these other languages include Python, SmallTalk, Eiffel, and COBOL. This means that you could, if you really wanted to, write pages using COBOL.Regardless of the language that you use to develop your pages, you need to understand that pages are compiled before they are executed. This means that pages can execute very quickly.The first time you request an page, the page is compiled into a .NET class, and the resulting class file is saved beneath a special directory on your server named Temporary Files. For each and every page, a corresponding class file appears in the Temporary Files directory. Whenever you request the same page in the future, the corresponding class file is executed.When an page is compiled, it is not compiled directly into machine code. Instead, it is compiled into an intermediate-level language called Microsoft Intermediate Language (MSIL). All .NET-compatible languages are compiled into this intermediate language.An page isn't compiled into native machine code until it is actually requested by a browser. At that point, the class file contained in the Temporary Files directory is compiled with the .NET framework Just in Time (JIT) compiler and executed.The magical aspect of this whole process is that it happens automatically in the background. All you have to do is create a text file with the source code for your page, and the .NET framework handles all the hard work of converting it into compiled code for you.ASP CLASSIC NOTEWhat about VBScript? Before , VBScript was the most popular language for developing Active Server Pages. does not support VBScript, and this is good news. Visual Basic is a superset of VBScript, which means that Visual Basic has all the functionality of VBScript and more. So, you have a richer set of functions and statements with Visual Basic.Furthermore, unlike VBScript, Visual Basic is a compiled language. This means that if you use Visual Basic to rewrite the same code that you wrote with VBScript, you can get better performance.If you have worked only with VBScript and not Visual Basic in the past, don't worry. Since VBScript is so closely related to Visual Basic, you'll find it easy to make the transition between the two languages.NOTEMicrosoft includes an interesting tool named the IL Disassembler (ILDASM) with the .NET framework. You can use this tool to view the disassembled code for any of the classes in the Temporary Files directory. It lists all the methods and properties of the class and enables you to view the intermediate-level code.This tool also works with all the controls discussed in this chapter. For example, you can use the IL Disassembler to view the intermediate-level code for the TextBox control (located in a file named System.Web.dll).Introducing Controls controls provide the dynamic and interactive portions of the user interface for your Web application. The controls render the content that the users of your Web site actually see and interact with. For example, you can use controls to create HTML form elements, interactive calendars, and rotating banner advertisements. controls coexist peacefully with HTML content. Typically, you create the static areas of your Web pages with normal HTML content and create the dynamic or interactive portions with controls.The best way to understand how controls work in an HTML page is to look at a simple Web Forms Page.Adding Application Logic to an PageThe second building block of an page is the application logic, which is the actual programming code in the page. You add application logic to a page to handle both control and page events.If a user clicks a Button control within an HTML form, for example, the Button control raises an event (the Click event). Typically, you want to add code to the page that does something in response to this event. For example, when someone clicks the Button control, you might want to save the form data to a file or database.Controls are not the only things that can raise events. An page itself raises several events every time it is requested. For example, whenever you request a page, the page's Load event is triggered. You can add application logic to the page that executes whenever the Load event occurs.2. Building Forms with Web Server ControlsBuilding Smart FormsYou use several of the basic Web controls to represent standard HTML form elements such as radio buttons, text boxes, and list boxes. You can use these controls in your pages to create the user interface for your Web application. The following sections provide detailed overviews and programming samples for each of these Web controls.Controlling Page NavigationIn the following sections, you learn how to control how a user moves from one page to another. First, you learn how to submit an HTML form to another page and retrieve form information. Next, you learn how to use the Redirect() method to automatically transfer a user to a new page. Finally, you learn how to link pages together with the HyperLink control.Applying Formatting to ControlsIn the following sections, you learn how to make more attractive Web forms. First, you look at an overview of the formatting properties common to all Web controls; they are the formatting properties of the base control class. Next, you learn how to apply Cascading Style Sheet styles and classes to Web controls.3. Performing Form Validation with Validation Controls Using Client-side ValidationTraditionally, Web developers have faced a tough choice when adding form validation logic to their pages. You can add form validation routines to yourserver-side code, or you can add the validation routines to your client-side code.The advantage of writing validation logic in client-side code is that you can provide instant feedback to your users. For example, if a user neglects to enter a value in a required form field, you can instantly display an error message without requiring a roundtrip back to the server.People really like client-side validation. It looks great and creates a better overall user experience. The problem, however, is that it does not work with all browsers. Not all browsers support JavaScript, and different versions of browsers support different versions of JavaScript, so client-side validation is never guaranteed to work.For this reason, in the past, many developers decided to add all their form validation logic exclusively to server-side code. Because server-side code functions correctly with any browser, this course of action was safer.Fortunately, the Validation controls discussed in this chapter do not force you to make this difficult choice. The Validation controls automatically generate both client-side and server-side code. If a browser is capable of supporting JavaScript, client-side validation scripts are automatically sent to the browser. If a browser is incapable of supporting JavaScript, the validation routines are automatically implemented in server-side code.You should be warned, however, that client-side validation works only with Microsoft Internet Explorer version 4.0 and higher. In particular, the client-side scripts discussed in this chapter do not work with any version of Netscape Navigator.Requiring Fields: The RequiredFieldValidator ControlYou use RequiredFieldValidator in a Web form to check whether a control has a value. Typically, you use this control with a TextBox control. However, nothing is wrong with using RequiredFieldValidator with other input controls such as RadioButtonList.Validating Expressions: The RegularExpressionValidator ControlYou can use RegularExpressionValidator to match the value entered into a form field to a regular expression. You can use this control to check whether a user has entered, for example, a valid e-mail address, telephone number, or username or password. Samples of how to use a regular expression to perform all these validation tasks are provided in the following sections.Comparing Values: The CompareValidator ControlThe CompareValidator control performs comparisons between the data entered into a form field and another value. The other value can be a fixed value, such as a particular number, or a value entered into another control.Summarizing Errors: The ValidationSummary ControlImagine that you have a form with 50 form fields. If you use only the Validation controls discussed in the previous sections of this chapter to display errors, seeing an error message on the page might be difficult. For example, you might have to scroll down to the 48th form field to find the error message.Fortunately, Microsoft includes a ValidationSummary control with the Validation controls. You can use this control to summarize all the errors at the top of a page, or wherever else you want.4. Advanced Control ProgrammingWorking with View StateBy default, almost all controls retain the values of their properties between form posts. For example, if you assign text to a Label control and submit the form, when the page is rendered again, the contents of the Label control are preserved.The magic of view state is that it does not depend on any special server or browser properties. In particular, it does not depend on cookies, session variables, or application variables. View state is implemented with a hidden form field called VIEWSTATE that is automatically created in every Web Forms Page.When used wisely, view state can have a dramatic and positive effect on the performance of your Web site. For example, if you display database data in a control that has view state enabled, you do not have to return to the database each time the page is posted back to the server. You can automatically preserve the data within the page's view state between form posts.Displaying and Hiding ContentImagine that you are creating a form with an optional section. For example, imagine that you are creating an online tax form, and you want to display or hide a section that contains questions that apply only to married tax filers.Or, imagine that you want to add an additional help button to the tax form. You might want to hide or display detailed instructions for completing form questions depending on a user's preferences.Finally, imagine that you want to break the tax form into multiple pages so that a person views only one part of the tax form at a time.In the following sections, you learn about the properties that you can use to hide and display controls in a form. You learn how to use the Visible and Enabled properties with individual controls and groups of controls to hide and display page content.Using the Visible and Enabled PropertiesEvery control, including both HTML and Web controls, has a Visible property that determines whether the control is rendered. When a control's Visible property has the value False, the control is not displayed on the page; the control is not processed for either pre-rendering or rendering.Web controls (but not every HTML control) have an additional property named Enabled. When Enabled has the value False and you are using Internet Explorer version 4.0 or higher, the control appears ghosted and no longer functions. When used with other browsers, such as Netscape Navigator, the control might not appear ghosted, but it does not function.Disabling View StateIn certain circumstances, you might want to disable view state for an individual control or for an page as a whole. For example, you might have a control that contains a lot of data (imagine a RadioButtonList control with 1,000 options). You might not want to load the data into the hidden __VIEWSTATE form field if you are worried that the form data would significantly slow down the rendering of the page.Using Rich ControlsIn the following sections, you learn how to use three of the more feature-rich controls in the framework. You learn how to use the Calendar control to display interactive calendars, the AdRotator control to display rotating banner advertisements, and the HTMLInputFile control to accept file uploads. 技术1.构建 页面 和结构 是微软.NET framework整体的一部分, 它包含一组大量的编程用的类,满足各种编程需要。

相关文档
最新文档