[Translation] 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, as part of the ASP. NET vNext solution, represents a fundamental change-how Microsoft builds and deploys web applications. Its goal is to create a host-independent framework to eliminate dependency on traditional System. Web assembly.

 

Microsoft feels that System. web needs to be removed because it is actually quite expensive. A typical HttpContext object graph can consume 30 K 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 2 K.

Microsoft believes that System. Web needs to be removed because it is expensive in actual use. In each request, a typical HttpContext object graph occupies 30 kb of memory. This is a high cost out of proportion compared to JSON communication. MVC 6 strives to reduce the overhead of "pre-requests" to about 2 K.

 

Authorized ded 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 contains Web APIs, Web Pages, and Microsoft removes the duplicates in the framework. This change means that MVC 6 will be self-hosted, like Web API 2 and 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."

To make the deployment easier and more reliable, vNext supports real parallel deployment. When using MVC 6 to build a website, the Assembly on which the site depends is not installed in GAC, but is similar to the DLL created by the developer. This means that you can update your application without affecting other applications on the same server.

 

Pay As You Go (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.

The MVC 6 design embodies the "pay-as-you-go" concept. Every feature you want to use will be enabled in the application startup program. You even need to call IBuilder. UseStaticFiles to provide static files.

 

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.

The working principle is: each site requires a class named Startup, which has a method of "void Configure (IBuilder app. In this method, you can call the required functional methods, such as "app. UseServices", to start some features such as 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 wocould use the UrlParameter. optional value for the same effect.

Routing is also set in the configuration method. Compared with the MVC 5 route, MVC 6 is somewhat similar, but not exactly the same. For example, in MVC 6, you can append a question mark to indicate an Optional parameter. In MVC 5, you need to define its default value UrlParameter. Optional to achieve the same effect.

 

Azure and PowerShell Based Deployments (Azure deployment and PowerShell-Based deployment)

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.

Microsoft is still promoting Azure deployment to a large extent as a standard method for website deployment. But they have realized that developers do not want to publish websites directly from Visual Studio. Therefore, as an alternative, PowerShell scripts are generated by default. In the New Visual Studio version, some basic PowerShell tools are included so that you can edit the generated scripts in Visual Studio.

 

The Build Process doesn' t Build (The Assembly is not built during The Build Process)

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.

In fact, ASP. NET vNext does not build anything during the generation process. No binary file is generated. It only runs the type check to detect the compilation errors and warnings of your code. Instead, the code will be quickly compiled when it is needed. This method of compiling code on demand is similar to the dynamic compilation mechanism in ASP. NET that we know well. This allows faster iterations, especially for large websites.

 

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 shocould have better performance, but cocould entail a much longer build process.

If you want to deploy a binary assembly on the server, you need to use the release function. This method will have a better performance, but it also means a longer build time.

 

Many APIs Will Be Moved or Removed (Some APIs Will Be Moved and deleted)

As mentioned before, they are processing the size of HttpContext from roughly 30 K per request to 2 K per request. this isn't free, the cost of that is a significantly defined CED 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.

As mentioned above, the size of HttpContext is reduced from about 30 K to 2 K for each request. This is not free, and the cost is to reduce the methods in the object and its sub-objects. When they finish, they may not only change the size.

 

In order to make this transition less painful, they intend to develop an FxCop like tool that will detect when legacy APIs CILS 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.

To make the technology transition smoother, Microsoft intends to develop a tool similar to FxCop to detect legacy API calls. Although it cannot automatically rewrite your code, it can at least tell you what to change before migrating to ASP. NET vNext and 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.

Sometimes, the change is only to call methods in a new assembly or package. In other cases, code may require a lot of refactoring. Since the product is still in alpha stage, the specific content of these changes is unknown.

 

Full Framework vs Cloud Optimized Framework (complete Framework VS Cloud Optimized 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.

The above warnings started to play a role. Even if the dependency on System. Web is eliminated, the dependency on. NET Framework is still maintained. If you take further actions and rely on the "cloud optimized Framework", you will not be able to use a lot. NET Framework API method, such as the System mentioned in Channel 9 Q & A session. 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.

The advantage of using the cloud-optimized Framework is that your site can include copies of Core CLR or Mono. You don't have to upgrade the device software for a website. You can even have different versions of CLR running different sites in parallel.

 

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 should also be "optimized" by resources. However, the details have not yet been disclosed.

 

Libraries vs Packages (library vs package)

Under. 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.

In vNext, the project references the NuGet package instead of a single class library. As you may know, a package can contain multiple versions of the same class library. ASP. NET vNext can be used to determine whether to load the Full. NET, Mono, or Core CLR version of a class library at runtime.

 

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.

If this doesn't sound attractive to you, you can also use the "portable class library ". Although it is not ready yet, Microsoft plans to create a PCL plane for the cloud-optimized Framework.

 

Mono is a Supported Platform (Mono Supported)

In the past the support story for Mono was essential "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.

In the past, for Mono, we often heard: "We want it to run well, but if it is not so satisfactory, you have to turn to Xamarin ". To achieve cross-platform ASP. NET vNext, Microsoft officially released the CLR that supports Mono. Microsoft will actively work with the Mono team to ensure integration test coverage.

 

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.

In addition, Microsoft did not provide Mono support in its payment channels. Microsoft only promises to maintain compatibility. If continuous integration testing suffers a defect, they will work with the Mono development team to solve it.

 

Cross Platform Development (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.

Microsoft is not only planning cross-platform development, but also promoting cross-platform development. Microsoft will provide batch files for major platforms such as OS X and Linux, so that users can package and deploy ASP. NET vNext projects without using Windows and Visual Studio.

 

Part of this is the KPM or the "Katana Packaged Modules", which were identified red 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.

One of them is KPM, which is inspired by Node Packaged Modules. Katana is a R & D project whose goal is to modularize ASP. net mvc with Owin. The background of KPM uses NuGet.

 

Trying it Out (try again)

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.
A preview version of ASP. NET vNext binaries has been released. Visual Studio is expected to support it in three to four weeks.