ASP論文外文翻譯---從底層了解ASP.NET的結(jié)構(gòu)

1、原文1A low-level Look at the ASP.NET ArchitectureAbstractASP.NET is a powerful platform for building Web applications that provides a tremendous amount of flexibility and power for building just about any kind of Web application. Most people are familiar only with the high level frameworks like WebFor

2、ms and WebServices which sit at the very top level of the ASP.NET hierarchy. In this article Ill describe the lower level aspects of ASP.NET and explain how requests move from Web Server to the ASP.NET runtime and then through the ASP.NET Http Pipeline to process requests. What is ASP.NETLets start

3、with a simple definition: What is ASP.NET? I like to define ASP.NET as follows:ASP.NET is a sophisticated engine using Managed Code for front to back processing of Web Requests.It's much more than just WebForms and Web ServicesASP.NET is a request processing engine. It takes an incoming request

4、and passes it through its internal pipeline to an end point where you as a developer can attach code to process that request. This engine is actually completely separated from HTTP or the Web Server. In fact, the HTTP Runtime is a component that you can host in your own applications outside of IIS o

5、r any server side application altogether. The runtime provides a complex yet very elegant mechanism for routing requests through this pipeline. There are a number of interrelated objects, most of which are extensible either via subclassing or through event interfaces at almost every level of the pro

6、cess, so the framework is highly extensible. Through this mechanism its possible to hook into very low level interfaces such as the caching, authentication and authorization. You can even filter content by pre or post processing requests or simply route incoming requests that match a specific signat

7、ure directly to your code or another URL. There are a lot of different ways to accomplish the same thing, but all of the approaches are straightforward to implement, yet provide flexibility in finding the best match for performance and ease of development.The entire ASP.NET engine was completely bui

8、lt in managed code and all of the extensibility functionality is provided via managed code extensions. This is a testament to the power of the .NET framework in its ability to build sophisticated and very performance oriented architectures. Above all though, the most impressive part of ASP.NET is th

9、e thoughtful design that makes the architecture easy to work with, yet provides hooks into just about any part of the request processing.With ASP.NET you can perform tasks that previously were the domain of ISAPI extensions and filters on IIS with some limitations, but its a lot closer than say ASP

10、was. ISAPI is a low level Win32 style API that had a very meager interface and was very difficult to work for sophisticated applications. Since ISAPI is very low level it also is very fast, but fairly unmanageable for application level development. So, ISAPI has been mainly relegated for some time t

11、o providing bridge interfaces to other application or platforms. But ISAPI isnt dead by any means. In fact, ASP.NET on Microsoft platforms interfaces with IIS through an ISAPI extension that hosts .NET and through it the ASP.NET runtime. ISAPI provides the core interface from the Web Server and ASP.

12、NET uses the unmanaged ISAPI code to retrieve input and send output back to the client. The content that ISAPI provides is available via common objects like HttpRequest and HttpResponse that expose the unmanaged data as managed objects with a nice and accessible interface.The ISAPI ConnectionISAPI i

13、s a low level unmanged Win32 API. The interfaces defined by the ISAPI spec are very simplistic and optimized for performance. They are very low level dealing with raw pointers and function pointer tables for callbacks - but they provide he lowest and most performance oriented interface that develope

14、rs and tool vendors can use to hook into IIS. Because ISAPI is very low level its not well suited for building application level code, and ISAPI tends to be used primarily as a bridge interface to provide Application Server type functionality to higher level tools. For example, ASP and ASP.NET both

15、are layered on top of ISAPI as is Cold Fusion, most Perl, PHP and JSP implementations running on IIS as well as many third party solutions such as my own Web Connection framework for Visual FoxPro. ISAPI is an excellent tool to provide the high performance plumbing interface to higher level applicat

16、ions, which can then abstract the information that ISAPI provides. In ASP and ASP.NET, the engines abstract the information provided by the ISAPI interface in the form of objects like Request and Response that read their content out of the ISAPI request information. Think of ISAPI as the plumbing. F

17、or ASP.NET the ISAPI dll is very lean and acts merely as a routing mechanism to pipe the inbound request into the ASP.NET runtime. All the heavy lifting and processing, and even the request thread management happens inside of the ASP.NET engine and your code.As a protocol ISAPI supports both ISAPI e

18、xtensions and ISAPI Filters. Extensions are a request handling interface and provide the logic to handle input and output with the Web Server its essentially a transaction interface. ASP and ASP.NET are implemented as ISAPI extensions. ISAPI filters are hook interfaces that allow the ability to look

19、 at EVERY request that comes into IIS and to modify the content or change the behavior of functionalities like Authentication. Incidentally ASP.NET maps ISAPI-like functionality via two concepts: Http Handlers (extensions) and Http Modules (filters). Well look at these later in more detail. ISAPI is

20、 the initial code point that marks the beginning of an ASP.NET request. ASP.NET maps various extensions to its ISAPI extension which lives in the .NET Framework directory:本文摘自http:/www.west-譯文1從底層了解ASP.NET的結(jié)構(gòu)· 摘要ASP.NET是一個(gè)用于構(gòu)建Web程序的強(qiáng)大平臺(tái)，提供了強(qiáng)大的柔性和能力以至于它可以構(gòu)建任意的Web程序。許多人僅僅對(duì)處于ASP.NET高層次的框架如：WebForm

21、s和WebServices比較熟悉，因此，在這篇文章里，我將會(huì)闡述有關(guān)ASP.NET比較底層的知識(shí)，并且將會(huì)解釋，如何將請(qǐng)求從Web Server移交給ASP.NET運(yùn)行時(shí)，然后通過ASP.NET HTTP管道處理這些請(qǐng)求。1 ASP.NET是什么？我們從最簡單的定義開始，ASP.NET是什么？我通常喜歡用如下語句來描述ASP.NET。ASP.NET是完全使用托管代碼處理Web請(qǐng)求的一個(gè)成熟引擎平臺(tái)。它不僅僅只是WebForms和WebServices。 ASP.NET是一個(gè)請(qǐng)求處理引擎。它獲取客戶端請(qǐng)求，然后通過它內(nèi)置的管道，把請(qǐng)求傳到一個(gè)終點(diǎn)，在這個(gè)終點(diǎn)，開發(fā)者可以添加處理這個(gè)請(qǐng)

22、求的邏輯代碼。實(shí)際上這個(gè)引擎和HTTP或者Web Server是完全分開的。事實(shí)上，HTTP運(yùn)行時(shí)是一個(gè)組件，你可以把它宿主在IIS之外的應(yīng)用程序上。甚至完全可以和其它的服務(wù)組合在一起。通過使用內(nèi)置的管道路由請(qǐng)求，HTTP運(yùn)行時(shí)提供了一套復(fù)雜的，但卻很優(yōu)雅的機(jī)制。在處理請(qǐng)求的每一個(gè)層面都牽涉到許多對(duì)象，但大多數(shù)對(duì)象都可以通過派生或者事件接口來擴(kuò)展。所以，此框架具有非常高的可擴(kuò)展性。通過這一套機(jī)制，可以進(jìn)入較低層次的接口如：緩存，身份驗(yàn)證，授權(quán)等是有可能的。你可以在處理請(qǐng)求之前或之后過濾內(nèi)容，或者僅僅把匹配指定簽名的客戶端請(qǐng)求直接路由到你的代碼里或轉(zhuǎn)向其它的URL。針對(duì)同一件事情，可以通過不同的

23、處理方法完成，而且實(shí)現(xiàn)代碼都非常的直觀。除此之外，在容易開發(fā)和性能之間，HTTP運(yùn)行時(shí)還提供了最佳的靈活性。 整個(gè)ASP.NET引擎完全構(gòu)建在托管代碼里，所有的擴(kuò)展性功能都是通過托管代碼的擴(kuò)展提供。對(duì)于功能強(qiáng)大的.NET框架而言，使用自己的東西，構(gòu)建一個(gè)成熟的、高性能的引擎體系結(jié)構(gòu)已經(jīng)成為一個(gè)遺囑。盡管如此，但重要的是，ASP.NET給人印象最深的是高瞻遠(yuǎn)矚的設(shè)計(jì)，這使得在其之上的工作變得非常容易，并且提供了幾乎可以鉤住請(qǐng)求處理當(dāng)中任意部分的能力。 使用ASP.NET可以完成一些任務(wù)，之前這些任務(wù)是使用IIS上的ISAPI擴(kuò)展和過濾來完成的。盡管還有一些限制，但與ASP相比

24、，已經(jīng)有了很大的進(jìn)步。ISAPI是底層Win32樣式的API，僅它的接口就有1兆，這對(duì)于大型的程序開發(fā)是非常困難的。由于ISAPI是底層的接口，因此它的速度也是非常的快。但對(duì)于企業(yè)級(jí)的程序開發(fā)是相當(dāng)?shù)碾y于管理的。所以，在一定的時(shí)間內(nèi)，ISAPI主要充當(dāng)其它應(yīng)用程序或平臺(tái)的橋接口。但是無論如何，ISAPI沒有被廢棄。事實(shí)上，微軟平臺(tái)上的ASP.NET和IIS的接口是通過宿主在.NET里的ISAPI擴(kuò)展來通信的，然后直達(dá)ASP.NET運(yùn)行時(shí)。ISAPI提供了與Web Server通信的核心接口，然后ASP.NET使用非托管代碼獲取請(qǐng)求以及對(duì)客戶端請(qǐng)求發(fā)出響應(yīng)。ISAPI提供的內(nèi)容經(jīng)由公共對(duì)象類似于

25、HttpRequest和HttpResponse，通過一個(gè)設(shè)計(jì)優(yōu)良的、可訪問的接口，以托管對(duì)象的方式暴露非托管數(shù)據(jù)。2 從瀏覽器到ASP.NET讓我們從一個(gè)典型的ASP.NET Web請(qǐng)求的生命周期的起點(diǎn)開始。用戶通過在瀏覽器中鍵入一個(gè)URL，點(diǎn)擊一個(gè)超鏈接，提交一個(gè)HTML表單（一個(gè)post請(qǐng)求），或者一個(gè)客戶端程序調(diào)用基于ASP.NET的WebService（通過ASP.NET提供服務(wù)）。在服務(wù)器端，IIS5或者IIS6將會(huì)收到這個(gè)請(qǐng)求。ASP.NET的底層通過ISAPI擴(kuò)展與IIS通信，然后，通過ASP.NET，這個(gè)請(qǐng)求通常被路由到一個(gè)帶有.aspx擴(kuò)展名的頁面。但是，這個(gè)處理過程如何工

26、作，則完全依賴于HTTP處理器（handler）的執(zhí)行。這個(gè)處理器將被安裝用于處理指定的擴(kuò)展。在IIS中，.aspx經(jīng)由“應(yīng)用程序擴(kuò)展”被映射到ASP.NET ISAPI的dll文件：aspnet_isapi.dll。每一個(gè)觸發(fā)ASP.NET的請(qǐng)求，都必須經(jīng)由一個(gè)已經(jīng)注冊(cè)的，并且指向aspnet_isapi.dll的擴(kuò)展名來標(biāo)識(shí)。注：ISAPI是自定義Web請(qǐng)求處理中第一個(gè)并且具有最高性能的IIS入口點(diǎn)。依靠擴(kuò)展名，ASP.NET把一個(gè)請(qǐng)求路由到一個(gè)恰當(dāng)?shù)奶幚砥?，該處理器則負(fù)責(zé)處理這個(gè)請(qǐng)求。舉個(gè)例子，WebServices的擴(kuò)展名.asmx不會(huì)把一個(gè)請(qǐng)求路由到磁盤上的某一個(gè)頁面，而是會(huì)路由到在

27、定義中附加了指定特性（WebMethodAttribute）的類，此特性會(huì)把它標(biāo)識(shí)成一個(gè)Web Services的實(shí)現(xiàn)。許多其它的處理器將隨著ASP.NET一起被安裝。當(dāng)然也可以定義你自己的處理器。在IIS里所有的HttpHandler被映射并指向ASP.NET ISAPI擴(kuò)展，并且這些HttpHandler也都在web.config里配置，用于把請(qǐng)求路由到指定的HTTP處理器里執(zhí)行。每一個(gè)處理器都是一個(gè).NET類，用于處理指定的擴(kuò)展。而這些處理器可以處理簡單到只有幾行代碼的Hello World，也可以處理復(fù)雜到類似ASP.NET的頁面以及執(zhí)行WebService。就目前而言，僅僅需要理解擴(kuò)

28、展就是一種基本的映射機(jī)制，ASP.NET用它可以從ISAPI里獲取一個(gè)請(qǐng)求，然后把請(qǐng)求路由到指定處理該請(qǐng)求的處理器中。原文2 Thirteen ASP.NET MVC extensibility points you have to knowAbstractOne of the main design principles ASP.NET MVC has been designed with is extensibility. Everything (or most of) in the processing pipeline is replaceable so, if you dont li

29、ke the conventions (or lack of them) that ASP.NET MVC uses, you can create your own services to support your conventions and inject them into the main pipeline.In this post Im going to show 13 extensibility points that every ASP.NET MVC developer should know, starting from the beginning of the pipel

30、ine and going forward till the rendering of the view.1. RouteConstraintUsually you could put some constrains on url parameters using regular expressions, but if your constrains depend on something that is not only about the single parameter, you can implement the IRouteConstrainss method and put you

31、r validation logic in it.One example of this is the validation of a date: imagine an url that has year, month and date on different url tokens, and you want to be able to validate that the three parts make a valid date.·2. RouteHandlerNot really specific to ASP.NET MVC, the RouteHandler is the

32、component that decide what to do after the route has been selected. Obviously if you change the RouteHandler you end up handling the request without ASP.NET MVC, but this can be useful if you want to handle a route directly with some specific HttpHanlders or even with a classic WebForm.3. Controller

33、FactoryThe controller factory is the component that, based on the route, chooses which controller to instantiate and instantiate it. The default factory looks for anything that implements IController and whose name ends with Controller, and than create an instance of it through reflection, using the

34、 parameter-less constructor. But if you want to use Dependency Injection you cannot use it, and you have to use a IoC aware controller factory: there are already controller factory for most of the IoC containers. You can find them in MvcContrib or having a look at the Ninject Controller Factory.4. A

35、ctionInvokerActionInvoker is responsible for invoking the action based on its name. The default action invoker looks for the action based on the method name, the action name and possibly other selector attributes. Then it invokes the action method together with any filter defined  and finally i

36、t executes the action result.If you read carefully you probably understood that most of the execution pipeline is inside the logic of the default ControllerActionInvoker class. So if you want to change any of these conventions, from the action methods selection logic, to the way http parameters are

37、mapped to action parameters, to the way filters are chosen and executed, you have to extend that class and override the method you want to change.A good example of this, is the NinjectActionInvoker I developed to allow injection of dependencies inside filters.5. ActionMethodSelectorAttributeActions,

38、 with the default action invoker, are selected based on their name, but you can finer tune the selection of actions implementing your own Method Selector. The framework already comes with the AcceptVerbs attribute that allows you to specify to which HTTP Verb an action has to respond to.A possible s

39、cenario for a custom selector attribute is if you want to choose one action or another based on languages supported by the browser or based on the type of browser, for example whether it is a mobile browser or a desktop browser.6. AuthorizationFilterThese kind of filters are executed before the acti

40、on is executed, and their role is to make sure the request is “valid”.There are already a few Authorization filters inside the framework, the most “famous” of which is the Authorize attribute that checks whether the current user is allowed to execute the action. Another is the the ValidateAntiForger

41、yToken that prevents CSRF attacks. If you want to implement your own authorization schema, the interface you have to implement is IAuthorizationFilter. An example could be the hour of the day.7. ActionFilterAction Filters are executed before and after an action is executed. One of the core filters i

42、s the OutputCache filter, but you can find many other usages for this filter. This is the most likely extension point you are going to use, as, IMHO, its critical to a good componentization of views: the controller only has to do its main stuff, and all the other data needed by the view must be retr

43、ieved from inside action filters.8. ModelBinderThe default model binder maps HTTP parameters to action method parameters using their names: a http parameter named user.address.city will be mapped to the City property of the Address object that itself is a property of the method parameter named user.

44、 The DefaultModelBinder works also with arrays, and other list types.But it can be pushed even further: for example you might use it to convert the id of the person directly to the Person object looking up on the database. This approach is explained better in the following post Timothy Khouri (aka S

45、ingingEels): Model Binders in ASP.NET MVC. The code is based on the preview 5, but the concept remains the same.·9. ControllerBaseAll controllers inherit from the base class Controller. A good way to encapsulate logic or conventions inside your actions is to create you own layer supertype and h

46、ave all your controllers to inherit from it.·10. ResultFilterLike the ActionFiters, the ResultFilters are execute before and after the ActionResult is executed. Again, the OutputCache filter is an example of a ResultFilter. The usual example that is done to explain this filter is logging. If yo

47、u want to log that a page has been returned to the user, you can write a custom RenderFilter that logs after the ActionResult has been executed.·11. ActionResultASP.NET MVC comes with many different kind of results to render views, to render JSON, plain text, files and to redirect to other acti

48、ons. But if you need some different kind of result you can write your own ActionResult and implement the ExecuteResult method. For example, if you want to send a PDF file as result you could write your own ActionResult that use a PDF library to generate the PDF. Another possible scenario is the RSS

49、feed: read more about how to write a RssResult in this post.Look at implementing a custom action result when the only peculiarity is how the result is returned to the user.·12. ViewEngineProbably you are not going to write your own view engine, but there are a few that you might consider using

50、instead of the default WebForm view engine. The most interesting one, IMHO, is Spark.But if you really want to write your own view engine, have a look at this post by Brad Wilson: Partial Rendering & View Engines in ASP.NET MVC.·13. HtmlHelperViews must be very dumb and thin, and they shoul

51、d only have html markup and calls to HtmlHelpers. There should be no code inside the views, so helpers come very handy for extracting the code from the view and putting it into something that is testable. As Rob Conery says: “If there's an IF, make a Helper”.What is an HtmlHelper? Basically its

52、just an extension method of the HtmlHelper class, but thats the only requirement.本文摘自.nz/譯文2ASP.NET MVC中你必須知道的13個(gè)擴(kuò)展點(diǎn) 摘要ASP.NET MVC設(shè)計(jì)的主要原則之一是可擴(kuò)展性。處理管線（processing pipeline）上的所有（或大多數(shù)）東西都是可替換的。因此，如果您不喜歡ASP.NET MVC所使用的約定（或缺乏某些約定），您可以創(chuàng)建自己的服務(wù)來支持您的約定，并將其注入到主管線中。在本文中，我們將從管線開始直到視圖呈現(xiàn)，逐一向您展示每個(gè)ASP.NET MVC開發(fā)者都必須了

53、解13個(gè)擴(kuò)展點(diǎn)。1.RouteConstraint通常情況下你可以使用正則表達(dá)式對(duì)url參數(shù)進(jìn)行約束，但如果您的約束不僅僅取決于單一參數(shù)，您可以實(shí)現(xiàn)IRouteConstrains的方法，并在其中添加你的驗(yàn)證邏輯。比如對(duì)日期的驗(yàn)證，url中可能會(huì)包含年、月、日，而你需要驗(yàn)證這三者是否可以組合成一個(gè)有效的日期。2.RouteHandlerRouteHandler是在路由選擇之后進(jìn)行處理的組件，它并不僅僅針對(duì)ASP.NET MVC。顯然，如果您改變了RouteHandler，那么對(duì)請(qǐng)求的處理將不再使用ASP.NET MVC，但這在您使用其他HttpHandler或經(jīng)典的WebForm進(jìn)行路由處理時(shí)

54、卻是非常有用的。3.ControllerFactoryControllerFactory是基于路由的組件，它選擇正確的controller并對(duì)其實(shí)例化。default factory會(huì)查找實(shí)現(xiàn)了IController并且以Controller結(jié)尾的類，然后通過反射使用無參構(gòu)造函數(shù)進(jìn)行實(shí)例化。但如果您希望使用依賴注入，就不能再使用default factory，而必須使用支持IoC的controller factory。MvcContrib和Ninject Controller Factory都包含支持IoC容器的controller factory。4.ActionInvokerActionI

55、nvoker顧名思義是負(fù)責(zé)調(diào)用（invoke）action的。默認(rèn)的action invoker通過方法名、action名或其他可能的selector attribute來查找action，然后調(diào)用action方法以及定義的filter，最終執(zhí)行得到action result。你會(huì)發(fā)現(xiàn)大部分執(zhí)行管線存在于ControllerActionInvoker類的邏輯之中。因此，如果希望改變這些約定，如action方法的選擇邏輯、http參數(shù)映射到action參數(shù)的方式、選擇和執(zhí)行filter的方式等，您需要擴(kuò)展該類并重寫需要修改的方法?？梢詤㈤哊injectActionInvoker I developed to allow injection of dependencies inside filters。5.ActionMethodSelectorAttribute使用默認(rèn)