原文: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类似。这意味着你可以更新你的应用,而不会影响同一服务器上的其他应用。
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来达到相同的效果。
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里编辑那些生成的脚本。
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.
如果你想将二进制的程序集部署在服务器上,需要使用发布功能。这种方式将有更好的表现,但也意味着更长的构建时间。
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阶段,这些变化的具体内容尚不可知。
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也应该被“资源优化”过。但具体内容,尚未透露。
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切面。
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开发团队一起解决它。
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。
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对其支持。
作者:MeteorSeed
感谢您阅读本文,如果您觉得有所收获,麻烦点一下右边的“推荐”,您的支持是对我最大的鼓励...
转载请注明出处。