Up until ASP.Net Core 3.1 [release date December 3, 2019], many ASP.Net developers referred to themselves as “MVC Developers”, or “ASP.Net MVC Developers” , or “ASP.Net Core MVC Developers”. This is because, up until that point there really was only one framework for developing websites in ASP.Net and ASP.Net Core. And that was MVC (Model-View-Controller).
Well that’s not totally true. In ASP.Net Full Framework, that is to say pre Core, and before MVC, the original and only framework for developing websites was WebForms.
What were WebForms?
WebForms were introduced along with ASP.Net 1.X [released in 2001] as a new way of developing websites. Web developers could now use an interface very similar to that of the now ancient VB6 (Visual Basic 6) IDE to develop websites in much the same manner they developed desktop applications; By dragging HTML and Server Controls from a toolbox to the design area such as Textbox controls, GridViews to show data, and database components to act as a bridge between a gridview and the database. Developers could use a split view to see the GUI at the top of the Visual Studio IDE and code at the bottom. This mannor of development hid the inner workings of HTML and HTTP from the web developer. For example a TextBox control from the toolbox would render itself as an HTML input element of type text. The idea was to widen the talent pool of web developers by letting desktop developers jump into web development without any knowledge of HTML, JavaScript, and CSS.
And so the ASP.Net Platform was born with a framework, WebForms, and components for working with data, authentication, profile data, sessions, etc. Developers were able to build applications and get them up and running very quickly. And the community had great excitement over the potential of ASP.Net and WebForms.
But the pitfalls soon reared their ugly heads. Developers really had no control over how html was rendered and we would spend hours reverse engineering the pipeline trying to make things work the way we wanted and the way we intended. There was no dependancy injection and there was tight coupling and no real conventionally agreed upon architecture. There were attempts to break up the different layers by separation of concern but the UI was tightly coupled to the backend which made separtion of concerns and testing difficult. The results were that maintenance and scalability could be a nightmare through out the lifetime of an application and most applications were not well tested (as far as any kind of unit testing goes).
Enter MVC
MVC (Model-View-Controller) was introduced into ASP.Net in 2008 with version 3.5 as an alternative paradigm to WebForms in developing web applications. MVC was an already existing software pattern that easily lended itself to the way the web works and made popular by the “Ruby on Rails” platform.
Understanding MVC
MVC embraces the way the web works and returns control over HTML and HTTP back to the developer. It also natively enforces separation of concerns.
The M in MVC stands for Model.
A Model is a representation of the obects and entities in our business domain such as a product, store, and location. The Model layer of MVC also controls data access and business rules. Data Access is part of the model and is most typically implimented by Entity Framework and Entity Framework Core. EF and EF Core can be configured to work with SQL Server, Oracle and No-SQL databases among others. Entity Framework is the most common ORM (Object Relational Mapping) tool used. An ORM maps your programming language’s objects to tables in the database so you can concentrate on your business domain and business objects and not have to worry about database tables and database configuration.
Although EF and EF Core are the most common ORMs used in ASP.Net and ASP.Net Core, every layer and component in MVC is customizable and replaceable. For instance, you could design and impliment your own Generic SQL based service where you pass in commands and parameters if you had reason and the inclination to do so.
The C in MVC stands for Controller.
A Controller is responsible for handling any http requests to the application. It looks at the Url of the request and picks out any route data, querystring data, or any post data for a form request. It uses this data to ask the model to make a database query or update. The model sends the results back to the controller and the controller sends those results to a View where the data can be processed and sent to the browser as HTML.
The V in MVC stands for View.
A View merely takes the data passed to it from the controller and prepares it to be rendered to the browser in HTML.
ASP.Net and ASP.Net Core use Razor Views with basic HTML and Razor Expressions interspersed throughout the HTML. Again although the Razor View Engine is what is used out of the box with ASP.Net and ASP.Net Core, every layer and component can be customized or written from scratch.
Advantages of MVC
So, now MVC addressed many of the pitfalls of WebForms.
Developers once again had complete control over HTML and unfettered access to HTTP.
By adhering to the three layers of the MVC Software pattern, Separation of Concerns is naturally achieved.
The UI is no longer tightly bound to the backend.
Services (or dependancies) can be created to access data and inserted into other components and services with Dependancy Injection.
By breaking up the three areas of responsibility and introducing DI (Dependancy Injection) the application is more easily, accurately and completely tested leading to more scalability and easier maintanence througout the lifetime of the application.
ASP.Net Core MVC – A total rewrite
ASP.Net, WebForms, and ASP.Net MVC have had a long and prosperous life starting from 2001 and up until 2020. We went from ASP.Net 1.x all the way up to ASP.Net 4.8 which was released with Visual Studio 2019 v.16.3. You can see the complete list of version releases over the years here: ASP.Net Version Release History . Understand up until this point when we have referred to ASP.Net and ASP.Net MVC we have been talking about the .Net Full Framwork”. Microsoft has continued to support and even invest in WebForms and MVC on the .Net Full Framework.
But after nearly 20 years once again some of the pitfalls began to rear their ugly heads.
Whenever Microsoft would release a new version of the .Net Framework, ASP.Net, or ASP.Net MVC, these changes would all have to be backward compatible and not break WebForms. They also had to make sure everything worked in all other types of applications, from Mobil to Desktop to Web. Everything was kind of all tied up together like spagetti. Multiple types of apps would load up the same System and System.Web dlls and so you were loading a bunch of features and components you may not ever use in your applications. This made load time and performance go down with each iteration and new version of ASP.Net and ASP.Net MVC. And although ASP.Net MVC was now popular and mature, many developers were thinking about looking for another development platform because the performance was just too lacking compared with other platforms like node.js. Something had to be done.
Microsoft decided to rewrite .Net from the ground up and call it .Net Core.
.Net Core [release date: June 27, 2016 with Visual Studio 2015 Update 3] included the new ASP.Net Core platform which had ASP.Net Core MVC as it’s Web Development Framework, Entity Framework Core for data access, and ASP.Net Identity Core for security and authentication.
The difference now is that instead of loading all of these spagetti dlls for every application, you only import the functionality you need through nuget packages.
This increases performance and has security advantages as well as leaving a smaller footprint for the application.
Another difference is that in ASP.Net MVC Full Framework there is still a lot of configuration in the web.config. In ASP.Net Core MVC, the emphasis is on convention rather then configuration making the application less rigid and more flexable. And any configuration and app settings you do need are mostly kept in json files making the application more robust and clould ready.
ASP.Net Core 2 MVC – Here come Razor Pages
With ASP.Net Core 2 came a new Framework: Razor Pages
[release date: August 14, 2017 with Visual Studio 2017 15.3]
Understanding Razor Pages
Think of Razor Pages as a hybrid between Web Forms and MVC.
WebForms had very simple set up and very little investment upfront. The advantage was for a simple application you could have something up and running very quickly. And this was the first attempt for ASP (after classic ASP) to separate presentation from code. So WebForms could be written with code and html all in the same page. Or, you had the option to add a code-behind page and separate out the code from the html. The problem was if the application was successful and the users asked for more and more features, the structure and code became a free-for-all. Spagetti. Brittle. Web Forms lend themselves very well to showing clients prototypes and for small short-lived applications. Think Annual Conference and Expo many Associtations and Non-Profits host once a year.
MVC on the other hand requires a lot of setup up front. But once you make that investment adding features is very quick and easy building on a solid infrastructure and architecture already in place.
Razor Pages like MVC have a Model and a View. But no controller. And the Model is a PageModel. Kind of like the old WebForms CodeBehind Page. But without all of the pitfalls of WebForms and with the advantages of MVC like Dependancy Injection and Testing.
And like WebForms and old classic ASP, you can include the code along with the HMTL all in one page or put the HTML in a Razor Page and have the code in the Razor Page’s Model Page.
But I think of Razor Pages as more of a sister to and much more related to MVC than to WebForms or classic ASP.
ASP.Net Core 3 – Dropping the MVC reference
ASP.Net Core 3 added yet another Framework: Blazor
[release date: September 23, 2019 with Visual Studio 2019]
MVC and Razor Pages are for the most part considered to be Server Side Web development frameworks. Although you can easily build very robust and sophisticated applications from top to bottom including the UI in these server side frameworks using Razor files.
There are also many Client Side Web development platfroms available such as Angular, React, and Vue to name a few. Client Side development platforms like these are commonly used to make SPA (Single Page Applications) when an application requires a very rich and robust user interface where application state needs to be kept during multiple HTTP requests. This is hard to do with Server Side Applcations which typically perform round trip updates. With SPAs the application stays loaded in the user’s browser keeping its state and updates are performed behind the scenes with client side languages like JavaScript, jQuery and TypeScript.
Understanding Blazor
Blazor attempts to give Server Side C# programmers the tools to mimic the behavior of client side languages like Angular without having to learn JavaScript and TypeScript. Blazor gives the appearance of keeping state on the client side. And a C# programmer can achieve this in the language they are used to.
Dropping the MVC reference
Well that was a long way to go to get back to my original point. But for those of us who grew up with the scripted (as opposed to compiled) and eloquently simple Classic ASP (which only had five objects), went through WebForms, adopted MVC, made the jump to Core, picked up Razor pages and are now getting into Blazor, we can no longer refer to ourselves as just, “MVC Developers”.
ASP.Net Core 3 just encompasses too much for that now with it’s three frameworks.
These frameworks can be used side by side in a complimentary fashion. I myself am starting to use MVC for the structure and larger parts of the program and redirect to Razor Pages for appendix or supplimental type parts of the application or for just simple pages. There is much less setup and complexity but the page stays ready to add in ASP.Net Core functionality into it’s Page Model Class.
Hello .Net 5!
.Net Core skipped over .Net Core 4.x and went straight to .Net 5… Well, kind of.
[.Net 5 was released on November 10, 2020.]
This is where .Net Framework and .Net Core merged.
.Net Framework version 4.8 was the last version of .Net Full Framework.
And the two merge in .Net 5.
The track going forward is really .Net Core continuted but Microsoft has dropped the Core reference to emphasize there is only one unified platform now going forward. Microsoft skipped .Net Core 4 to avoid confusion with .Net Full Framework 4.
There will only be one .Net Framework.
Microsoft is creating one unified platform – .Net.
- No Full Framework
- Dropping the word Core to emphasize one framework (although Microsoft says feel free to use the word Core).
Here is a a quote from Richard Lander, .Net Program Manager at Microsoft,
There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS, and WebAssembly and more. We will introduce new .NET APIs, runtime capabilities and language features as part of .NET 5.
.Net 5 will not have LTD (Long Time Support). So if you are about to build a new application I would hold out for .Net 6. Microsoft’s road map is to release a new edition of .Net every year around November.
Here is a history of .Net Core version release dates and the projected dates for 2007 and 2008.
What’s Next? – Here comes .Net 6.
.Net 6 was released February 8, 2022 with Visual Studio 2022 Version 17.0. As far as I can see so far there have not been a lot of changes from .Net 5 to .Net 6. There are some added features to Visual Studio 2022 like suggestions along with Intellisence. Visual Studio shows suggested text as you type and you just click tab to accept it or just keep typing your code if not. Visual Studio is surprisingly good at guessing what the rest of your line of code is going to be.
Feel free to get a jump on all the great tutorials and documentation here.
