[譯]Introducing ASP.NET vNext and MVC 6


原文:http://www.infoq.com/news/2014/05/ASP.NET-vNext?utm_source=tuicool

 

  Part of the ASP.NET vNext initiative, ASP.NET MVC 6 represents a fundamental change to how Microsoft constructs and deploys web frameworks. The goal is to create a host agnostic framework that eliminates the dependencies on the legacy System.Web infrastructure.

  ASP.NET MVC 6作為ASP.NET vNext解決方案的一部分,體現了一個根本性的改變——微軟如何構建和部署web應用。它的目標是:創建一個宿主無關的框架,以便消除對傳統的System.Web程序集的依賴。

 

  Microsoft feels that System.Web needs to be removed because it is actually quite expensive. A typical HttpContext object graph can consume 30K of memory per request. When working with small JSON-style requests this represents a disproportionately high cost. With MVC 6 new design, the pre-request overhead drops to roughly 2K.

  微軟認為System.Web需要被移除,因為它在實際使用中相當昂貴。在每次請求中,一個典型的HttpContext對象圖會占用30K內存。這與使用JSON通信相比,造成不成比例的高成本。MVC 6力求將“預請求”的開銷下降到大約2K。

 

  Included in MVC 6 is Web API and Web Pages, allowing Microsoft to remove a lot of the overlap between the three frameworks. One result of this change means that MVC will be self-hosting just like Web API 2 and SignalR 2.

  MVC6中包含Web API,Web Pages,微軟移除了框架中重復的部分,這種變化意味着MVC 6將是自托管的,如同Web API 2和SignalR 2。

 

  In order to make deployment easier and more reliable, “vNext will support true side-by-side deployment.” Rather than being installed in the GAC, each MVC library needed for a given web site will be referenced like a normal developer-created DLL. “That means you can update your app without affecting other applications on the same server.”

   為了使部署更容易和可靠,vNext將支持真正的並行部署。使用MVC 6構建網站時,站點依賴的程序集不會安裝在GAC中而是和開發者創建的DLL類似。這意味着你可以更新你的應用,而不會影響同一服務器上的其他應用。

 

Pay As You Go (現收現付)

  MVC 6 is built on a “pay as you go” philosophy. Each feature that you wish to use has to be explicitly turned on in the application startup routine. Even serving up static files requires calling IBuilder.UseStaticFiles.

  MVC 6的設計體現了“現收現付”理念。你希望使用的每一個功能都會在應用啟動程序中開啟。甚至提供靜態文件需要調IBuilder.UseStaticFiles。

 

  The way this works is that each website needs to have a class named Startup and this class must have a method called “void Configure (IBuilder app)”. Inside this method you can call functions such as “app.UseServices” to enable features such as MVC.

  其工作原理是:每個站點都需要有一個名為Startup的類,這個類有一個方法“void Configure (IBuilder app)”方法。在該方法中可以調用你需要的功能方法,如“app.UseServices”,以便啟動某些特性如MVC。

 

  Routing is also setup in the Configuration method. MVC 6 routes are similar, but not identical, to MVC 5 routes. For example, a question mark can be added to a fragment to make it optional in MVC 6. In MVC 5 you would use the UrlParameter.Optional value for the same effect.

  路由也在配置方法中進行設置。 與MVC 5的路由相比,MVC 6有些相似,但不完全相同。例如,在MVC 6中可以通過追加問號表示可選參數,而在MVC 5中,需要將其默認值定義為UrlParameter.Optional來達到相同的效果。

 

Azure and PowerShell Based Deployments (Azure部署和基於PowerShell的部署)

  Microsoft is still heavily pushing Azure as the standard way to deploy websites. But they have realized that developers are leery of publishing websites directly from Visual Studio. So instead they will generate PowerShell deployment scripts by default. These can then be edited inside Visual Studio, which now has basic tooling support for PowerShell.

  微軟仍在很大程度上推動讓Azure部署成為網站部署的標准方式。但他們已經意識到,開發者們都不願意直接從Visual Studio發布網站。所以,作為替代,默認情況下會生成PowerShell腳本。在新版Visual Studio中,已經包含了一些PowerShell的基本工具,以便用戶能夠在Visual Studio里編輯那些生成的腳本。

 

The Build Process Doesn’t Build (在生成過程中不會構建程序集)

  In ASP.NET vNext the build process does not actually build anything. No binaries are generated, it merely runs the type checker to ensure you don’t have any errors or warnings that need to be addressed. Instead the code is compiled on the fly in an as-needed basis, much like we already see with ASP.NET Web Pages. This allows for faster iterations, especially over large websites.

  實際上,ASP.NET vNext在生成過程中並沒有構建任何東西。不生成任何二進制文件,它只是運行類型檢查,以發現你代碼的編譯時錯誤和警告。作為代替,代碼會在其被需要時,快速地被編譯,這種按需編譯代碼的方式,很像我們所熟知的ASP.NET中的動態編譯機制。這允許更快的迭代,尤其是在大型網站中。

 

  If you want actual binaries to be deployed on a server you need to run the package and publish command. Eventually this will offer several options from source code only, which will continue to compile on the fly, all the way up to natively compiled. The latter should have better performance, but could entail a much longer build process.

  如果你想將二進制的程序集部署在服務器上,需要使用發布功能。這種方式將有更好的表現,但也意味着更長的構建時間。

 

Many APIs Will Be Moved or Removed (一些API將被移動和刪除)

  As mentioned before, they are reducing the size of HttpContext from roughly 30K per request to 2K per request. This isn’t free, the cost of that is a significantly reduced set of methods on that object and its children. And by the time they are done it is probably not going to be the only API trimmed down in size.

  正如前面提到的,既減少HttpContext的大小從大約每個請求30K到2K。這不是免費得來的,其代價是減少該對象及其子對象中的方法。當他們完成時,可能改變的不僅僅是大小。

 

  In order to make this transition less painful, they intend to develop an FxCop like tool that will detect when legacy APIs calls are being made. While it won’t be able to automatically rewrite your code, it can at least tell you what needs to be changed before migrating to ASP.NET vNext and MVC 6.

  為了使技術過渡更為平滑,微軟打算開發一個類似FxCop的工具,用於檢測遺留的API調用。雖然它不能自動重寫你的代碼,它至少可以告訴你需要遷移到ASP.NET vNext和MVC 6前要改變什么。

 

  Sometimes the change will just involve calling a different method from an optional package or library. Other times the code will need to be significantly rewritten. Since the product is still in alpha a complete list of these changes is not yet available.

  有時,變化僅僅是調用新的程序集或包中的方法。而其它時候,代碼可能需要大量重構。由於該產品仍然處於alpha階段,這些變化的具體內容尚不可知。

 

Full Framework vs Cloud Optimized Framework (完整的Framework VS 雲優化的Framework)

  The above warnings come into play because they are removing their dependency on System.Web but otherwise stay on the full .NET Framework. If you take the next step and go with what they are calling the “Cloud Optimized Framework” then you lose access to even more APIs. In the Channel 9 Q&A session they mentioned System.Drawing as an example of what you can’t use.

  上述警告開始發揮作用,即使消除對System.Web的依賴,但仍然保持着對.NET Framework的依賴。如果你采取更進一步的行動,依賴“雲優化的Framework”,那么,你將無法使用很多.NET Framework的API方法,例如在Channel 9 Q&A session中提到的System.Drawing。

 

  The advantage of using the Cloud Optimized Framework is that you can include a copy of the Core (or Mono) CLR with your website. You no longer have to upgrade .NET on the entire machine for the sake of one website. You can even have different versions of the CLR for different websites running side by side.

  利用雲優化的Framework的好處是,你的站點可以包括Core CLR或Mono的副本。你不必再為某個網站而升級設備軟件,你甚至可以有不同版本的CLR並行地運行不同的站點。

 

  The Core CLR is also supposed to be tuned with a “high resource-efficient optimization”. Exactly what that means has not yet been revealed.

  Core CLR也應該被“資源優化”過。但具體內容,尚未透露。

 

Libraries vs Packages (庫 vs 包)

  Under the .NET vNext model, projects don’t reference individual libraries anymore. Instead they reference NuGet Packages. As you probably know, packages can contain multiple versions of a library divided by target platform. ASP.NET vNext can leverage this to decide at runtime whether to load the Full .NET, Mono, or Core CLR version of a given library.

  在vNext中,項目不引用單個類庫,而是引用NuGet包。正如你可能知道的,包可以包含同一類庫的多個版本。ASP.NET vNext可以利用這個來決定在運行時是否加載某個類庫的Full .NET、Mono或Core CLR版本。

 

  If this doesn’t sound palatable to you, there will also the option to use Portable Class Libraries. Though it isn’t ready yet, they plan on creating a PCL profile for the Cloud Optimized Framework.

  如果這聽起來不吸引你,你也可以使用“可移植類庫”。盡管它還沒有准備好,微軟計划為雲優化的Framework創建PCL切面。

 

Mono is a Supported Platform (支持Mono)

  In the past the support story for Mono was essentially “we hope it runs, but if it doesn’t then you need to talk to Xamarin”. Now Microsoft is billing Mono as the official cross-platform CLR for ASP.NET vNext. To that effect they are actively working with the Mono teams to ensure it has everything they need and will include Mono in their Continuous Integration testing.

  過去,對於Mono,我們常常聽到:“我們希望它運行的很好,但如果它不那么盡如人意,你就只能求助於Xamarin了”。現在,為了實現ASP.NET vNext的跨平台性,微軟官方正式發布支持Mono的CLR。微軟將積極與Mono團隊合作,以確保集成測試的覆蓋率。

 

  That said, Microsoft isn’t offering official support for Mono via their paid support channels. They are only promising to maintain compatibility and that if a CI test fails they will work with the Mono teams to fix it.

  此外,微軟沒有在其支付渠道為Mono提供支持。微軟只許諾維持兼容性,如果持續集成測試出現缺陷,他們將與Mono開發團隊一起解決它。

 

Cross Platform Development (跨平台開發)

  Not only is Microsoft planning for cross-platform deployment, they are also enabling cross-platform development. Batch files for the major platforms such as OS X and Linux will be provided so that you can package and deploy ASP.NET vNext projects without needing Windows and Visual Studio.

  微軟不僅在計划跨平台開發,他們也在推動跨平台開發。微軟會為諸如OS X和Linux等主要平台提供批處理文件,以便用戶可以在不借助Windows平台和Visual Studio的情況下,打包和部署ASP.NET vNext項目。

 

  Part of this is the KPM or the “Katana Packaged Modules”, which were inspired by Node Packaged Modules. Katana was a research project for modularizing ASP.NET MVC for use on Owin. KPM will use the NuGet repository on the backend.

  其中之一就是KPM,KPM是受Node Packaged Modules啟發得來的。Katana是一個研發項目,其目標借助Owin讓ASP.NET MVC模塊化。KPM的后台將使用NuGet。

 

Trying it Out (嘗試一下)

  The preview version of the ASP.NET vNext binaries are available now. Visual Studio support is expected to be available in three to four weeks.
  目前已經發布了ASP.NET vNext binaries的預覽版。預計會在三至四周后使Visual Studio對其支持。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM