.NET Core - MVC

Observations about .NET Core, MVC and converting YetaWF from ASP.NET MVC5 to .NET Core MVC. The new .NET Core has great new features. Getting there from an existing MVC 5 app is HARD!

Goodbye Razor

08/27/2018

Goodbye Razor. You were a good idea whose time has passed.

Razor sure simplified writing/mixing C# andf HTML and rendering HTML. We used to be able to write cshtml pages, hit F5 in our browser to load the new page. That was pretty useful. With ASP.NET Core, that's no longer the case. You have to restart the site before the cshtml page gets recompiled.

Compiling/verifying cshtml files was always possible (in ASP.NET 4) with a command line tool. With ASP.NET Core we have to publish the site to get all cshtml "compiled". But then we can't "preload" them once the site is deployed. There doesn't seem to be a command line tool for ASP.NET Core. (There wasn't the last time I checked which was about one year ago).

I often use "Find All References" in Visual Studio to find all uses of a variable for example. Unfortunately, any use of a variable in a cshtml file is not shown (well, in a few cases they are shown, go figure - not reliable). So that's not really all that useful.

What's left? Razor still offers an easy way to mix HTML and rendering code using C#. This is the main selling point for Razor and is still valid for a lot of users, which is why Razor remains a useful tool. But this one remaining strength of Razor is not needed in YetaWF.

YetaWF has completely transitioned to rendering all views and templates (DisplayTemplate, EditorTemplate) using C#. Writing the code really isn't much harder than with Razor. There are just a few pages left using Razor, the main "skin" pages which define the overall appearance of pages. We'll probably eliminate them down the road too.

So what do we have now? C# rendering of views using string formatting (as in string s = $"<a href={HAE(myvariable)}>some link</a>") isn't much harder to read or write than Razor code. Yes, it's a little harder, but it's worth the price. Encoding is the responsibility of the programmer, that's where the HAE method (HAE = Html Attribute Encoding) comes into play. That's the "hard" part.

There is no more "precompiling" cshtml files. All views and templates are C# files. They're compiled by the C# compiler. Ready to go! Our typical site starts up in about 5 seconds. Views are ready and don't slow things down. No need to compile a view or template when it's hit the first time.

"Find All References" in Visual Studio now actually does what it promises. It finds all references! For refactoring tasks, this is invaluable. No more surprise failures when a view or template is rendered for the first time.

A side-effect of the transition away from Razor to our own C# rendering was the immediate simplification of templates. Particularly complex templates, i.e., templates that use other templates, have become so much easier to implement and test.

Unexpectedly, page rendering performance has improved by approximately 15%. That means a page renders 15% faster! And we're comparing pages that were already precompiled (and are cached) with our new C# rendering code. We're not totally sure how that happened, other than suspect that the memory streams used by Razor are just not as fast as StringBuilder, which is used in our code. And maybe the fact that we can call views/templates directly rather than going through ASP.NET (Core). In any case, the result speaks for itself. Of course, our new C# rendering code will never need to be "precompiled" once deployed, so the site never has to precompile a view after a site restart. In this scenario, the C# rendering code performs about 1000% better than a Razor page.

Overall, Razor had a good run, but it's time, for us at least, to move on. 

No Comments

Be the first to add a comment!

Add New Comment

Complete this simple form to add a comment to this blog entry.