[譯]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對其支持。