Cromulent Cromulent - 1 month ago 31
C# Question

Which should I use? ASP.NET MVC 5 or ASP.NET Core MVC?

I'm new to the world of Microsoft programming having been Linux based (or at least Unix) for most of my programming career. For various reasons I am making the move to Microsoft technologies for a new website that I am planning on developing and I have to admit to being somewhat confused.

So as far as I can tell there two popular frameworks on the .NET platform. ASP.NET MVC 5 and ASP.NET Core MVC. It is my understanding that ASP.NET Core MVC is essentially just ASP.NET MVC 6 as it is a complete rewrite of the old system but I've also heard that it doesn't yet support all the features of the older ASP.NET MVC 5 in particular I was told it didn't support SignalR which sounds like an interesting technology although I'm not entirely sure if I will end up using it.

I've tried doing some Google searches to see what exactly is new in ASP.NET Core MVC to see if there are any new features that would be useful to me but apart from the fact that it is now cross platform and can now run on Mac OS X as well as Linux I can't find any actual new features. As useful as it would be to have the option to run on Linux in the future I think I'll be sticking to the Windows platform so that particular feature doesn't interest me that much.

So are there any killer features in ASP.NET Core MVC that should make me prefer to use that version or am I better off using ASP.NET MVC 5 for the foreseeable future?

So what would you do for a new project that might well need to be supported for 5 years or more?

Answer

I have been working with ordinary ASP.NET for a long time and had tried to use the new ASP.NET Core recently. I can telly you that I like it way better than the previous. It is definitely a step forward for Microsoft regardless of the fact if it's going to run on Linux or not. I can state this feature as those that were most compelling to me:

  • Combined pipeline for MVC and Web Api. In previous versions of ASP.NET you had two separate pipelines which resulted in e.g. double exception handling, writing double filter for authorization and so on. Now it's all combined and you just return either a View or an object which is being transformed to JSON.
  • Open and extensible framework. Many times with the old solution you were stuck with a NullReference or some other exception that happened in the framework and Google was the only way to go and if you were lucky, you can get the answer. It was a big black box. With a new modular approach you have control over all parts, you can turn on the logging for system classes which became way way better and helps you tackle the problem. Especially good for routing problems, when you don't know why your route does not get hit. Microsoft logging tells you exactly now how it tries to resolve the routes so you can track what's wrong.
  • Environments support out of the box. Microsoft has added different environments as first-class citizens. E.g. you can have app.projection.json and app.development.json that is handled in an easy way compared to the annoying web.config troubles for different settings on production and development. The same way you can have different files loaded in web based on the environment
  • Logging support for multiple providers. It was absolutely not too hard to do before, but now it's built-in and very easy to use.
  • Configuration is easier. Loading configuration is way simpler now than it was in the older version with one web.config file. You can just go on and load config from various places like json file and override it with environment variables that you will set in you production environment only (which is neat for Azure e.g.).
  • Full power of node.js tooling for frontend. It's a bit a matter of preference if that a benefit or a drawback really, but the facts are that Microsoft has decided themselves to not develop their frontend tooling (like bundling, etc.) but to leverage all that node.js has to offer. It's a first-class citizen now and comes real handy if you use e.g. Angular2 with Typescript. It's still possible to use node.js in older ASP.Net, but here it comes out of the box and seems to be a bit better supported by new .Net Core project structure in Visual Studio.
  • Built-in DI. While there was no trouble really to turn on DI in older ASP.NET especially with all the packages from SimpleInjector e.g. (apart from some nasty injection in filters and attributes), new system almost forces you to use it, so if your colleagues don't like DI for some reason you'll have one more argument for it.
  • Performance. Since the new framework is so light-weight and modular it should provide a way better performance for the raw requests (overhead for the framework code itself, not for you business logic.) as well as smaller memory footprint. You can check this post for some details e.g. + some official benchmarks here. They claim performance for simple requests is at least 6 times higher (~50K rps vs ~300K rps).

Some downsides:

  • Pre-release tooling. The tooling is not yet "release version", as well as some libraries, but all seem to be rather stable nonetheless and moreover Microsoft working hard to fix it.
  • Troubles with referencing old libraries. There are many libraries that were build before .Net Core and if they are not updated by their authors, it can be hard to use it even though possible. But if you are not planning to use any specific 3d party dll's this should not be a big deal.

All in all it's the platform of the future from Microsoft in my mind and they keep most focus on it. It's a platform I like to work with as well (so I personally would do new development there if I have a chance if I don't need SignalR right now e.g.). You can say it's like upgrading from a good known petrol car to a Tesla. You have petrol stations and maintenance everywhere easily accessible for petrol cars, but Tesla is the future :)

Microsoft is of course adding all the missing features in the future, hopefully nearest future, so the choice is yours.