Post 1 in a series of many posts about .net core 2 MVC

This will be the first post in what I am learning about .net Core 2 MVC. This is more about the history of ASP.net and why .net core was developed.  I am reading through this book Pro ASP.NET Core MVC 2 so some of this is direct quotes from that book. I try to use my own words on this but he says it so much better so I quote his words some of the times.

The original ASP.NET was introduced in 2002, at a time when Microsoft was trying to protect its dominant position in PC development and saw the internet as a threat. The stack as it appeared then was .NET – a multilanguage-managed code platform (Which was brand new at the time) Just above that was ASP.NET –  A way to host .NET applications in IIS (Microsoft’s web server), letting you interact with HTTP request and responses. Above that in the stack was ASP.NET Web Forms – A set of UI components (pages, buttons, ect…) plus a stateful, object-oriented GUI programming model. ASP.NET Web Forms was what Microsoft used to abstract out the HTTP (HyperText Transfer Protocol), HTML (HyperText Markup Language) and state of objects. It was their way of trying to make web programming like Desktop programming. The main problems with ASP.NET Forms were view state weight, page life cycle, separation of concerns, very limited control over HTML, leaky abstraction, low testability.

View state weight
View state is the mechanism for maintaining state across requests. This resulted in large blocks of data being transferred between client and servers. That impacts response times as well as increases the needed server bandwidth.
page life cycle
The mechanism for connection client-side events with server-side events handler code. This part of the page lifecycle could be very delicate and complicated. Very few developers could manipulate the control hierarchy at runtime without creating view state errors or finding some of the event handlers just quit working.
separation of concerns
ASP.NET web forms code-behind model created a false sense of separation of concerns by taking application code out of the HTML markup and into a separate code-behind class. This was designed to separate logic and presentation but developers were encouraged to mix presentation code in with their application logic in the same gigantic code-behind classes. The end result could be very fragile and hard to follow.
HTML Control
server controls rendered themselves in HTML but not always the correct HTML or the HTML you wanted. The early versions of ASP.NET failed to meet web standards or make good use of Cascading Style Sheets (CSS), and server controls generated unpredictable and complex ID attributes that were hard to access using Javascript. This has improved in recent releases but it’s still not easy to get HTML you want.
leaky abstraction
Web Forms tried to hide HTML and HTTP so as you tried to implement custom behaviors, you frequently fell out of the abstraction. This would force you to try and reverse engineer the postback event mechanism or perform some strange acts to generate the desired HTML.
low testability
The way everything was tightly coupled made unit testing virtually impossible. Integration testing could be a challenge as well.

In 2007 Microsoft announced the MVC framework. This was in response to the criticism of web forms and emerging new technology like ruby on rails. They decided to use the ASP.NET platform as the base this MVC would run on. That probably made sense to them at the time and gave them a bit of a head start. This required them to compromise on since the MVC framework was being grafted onto something that was designed to work with Web Forms. Then as the MVC framework grew in popularity Microsoft started to take some of the core features and add them to web forms. The results were odd, to say the least. They created some design quirks to support the MVC framework that was extended to support web forms. Then further quirks were created when they had to make everything fit together. They also started to expand ASP.NET with new frameworks for the creation of web services (Web API) and real-time communication (SignalR). These new frameworks add their own configurations and development conventions. They each had their own benefits and oddities. The overall results were all kinds of fragmented. That resulted in a big mess when trying to get things to work together across frameworks.

In 2015, Microsoft announced a new direction for ASP.NET and MVC. This would eventually produce ASP.NET Core MVC. ASP.net Core is built on .NET CORE which is a cross-platform version of .NET framework that removed the windows specific libraries (APIs). In my opinion, this is a brilliant move for Microsoft. What they have done is created a .NET that is running cross-platform so they have increased the number of possible users of .NET. Especially now when web applications are being hosted in small containers in cloud platforms. Now using .NET CORE developers can create web application hosted on Linux and MacOS. This means that a developer could develop an ASP.NET Core web application and host it on a LINUX machine! That is a big move for Microsoft from where they were in the past.

ASP.net Core is a completely new framework. It is simpler, easier to work with and is free of the tight coupling of Web Forms. It is based on .NET Core so it supports the development of web applications on a range of platforms and container. It provides the functionality to generate complex content and allows unit testing to be simpler and more predictable. ASP.NET CORE MVC 2 requires .NET Core 2, which has a much-expanded API surface and is now supported on additional Linux distributions.ASP.NET Core follows a pattern called (Model-View-Controller) MVC, which guides the format of an ASP.NET web application and the interaction between its components. The MVC pattern is not new it dates back to 1978 and the Smalltalk project at Xerox PARC. MVC has gained popularity today as a pattern for web applications because the way web applications fit the pattern. The MVC pattern follow the cycle of a user takes an action and in response, the application changes its data model and delivers a view to the user. This follows well with the web applications delivered over HTTP request and responses. Web applications also are typically combined into tiers or layers like the data layer, repository, and display layer this fits well into the MVC pattern. ASP.NET Core MVC implements MVC and does it well. This provides a good separation of concerned compared to Web Forms. In fact, ASP.NET Core MVC implements a variant of MVC pattern that is well suited for web applications.

ASP.NET Core MVC and ASP.NET Core are highly extensible since they are built as a series of independent components that have well-defined characteristics that satisfy a .NET interface or are built on an abstract base class. This makes it where you can easily replace key components with ones of your own implementation. This allows you to use the default implementation of the component, derive a subclass of the component, or replace the component entirely with a new implementation. Along with this extensibility comes tight control over HTTP and HTML ASP.NET Core MVC produces clean and standards compliant markup. With ASP.NET Core MVC it encourages you to craft simple yet elegant markup styled with CSS. If you need to throw in some ready-made widgets for some complex UI elements then ASP.NET Core MVC allows that to happen. It also allows the use of best of breed client-side libraries like JQuery, Angular, or Bootstrap CSS library. This new ASP.NET Core MVC is vastly superior compared with WebForms in my opinion. This new structure gives you a great start in making the application testable and maintainable because it naturally separates out application concerns. This makes unit testing much easier when the application is separated into independent pieces. This new structure also works very well with UI automation testing since you no longer need to worry about what HTML is rendered or how the CSS classes and ID will be generated. This just lends itself to making your code way more testable both from the UI and the classes. This is great for finding issues before they make it to production environments.

This new version of ASP.NET Core MVC has a powerful routing system. You might recall seeing a URL like:

VS the new version of ASP.NET Core

This new routing makes URL’s more intuitive and it also follows how I typically see restful API URLs. This also helps with search engines it appears to me that keywords in the URL have some weight in how you rank in searches. This allows the programmer to be in control of the URL schema and making these clean URLs meaningful to their applications. This means that the programmer can create a pattern of URLs that are meaningful to the users of the application.

This .NET platform is evolving with every major release supporting and even defining some of the state-of-the-art aspects of modern programming. Since this is a brand new framework built on .NET CORE it can take full advantage of the available API’s that include the Await keyword, extension methods, lambda expressions, anonymous and dynamic types and Language Integrated Query (LINQ). Many of the ASP.NET Core MVC API methods follow a cleaner more expressive coding pattern. This makes for cleaner more understandable code that performs well and does what is expected. Since this is all built on .NET Core that means that it is now cross-platform deployable. Previous versions of ASP.NET were specific to windows so you had to have a windows desktop to write the applications and a windows server to host them. This has changed with the .NET Core framework. .NET Core is available for different platforms, including MacOS and a range of Linux distributions. This makes it easier to deploy ASP.NET MVC Applications and it has good support for working with application containers such as Docker. Not to mention that ASP.NET Core MVC is open source which is not like all previous versions of Microsofts web development platforms. This means you are free to download the source code and even modify it to compile your own version.

That will do it for this post. I hope that by doing this regularly it helps me to learn this as I am working through the book Pro ASP.NET Core MVC 2 which seems to be a great book so far. The next post will contain code since the next chapter starts coding.

Leave a Reply

Your email address will not be published. Required fields are marked *