Model View Controller (MVC)
MVC is a design pattern used to decouple user-interface (view), data (model), and application logic (controller). This pattern helps to achieve separation of concerns.
Using the MVC pattern for websites, requests are routed to a Controller that is responsible for working with the Model to perform actions and/or retrieve data. The Controller chooses the View to display, and provides it with the Model. The View renders the final page, based on the data in the Model.
The Model-View-Controller (MVC) architectural pattern separates an application into three main groups of components: Models, Views, and Controllers. This pattern helps to achieve separation of concerns. Using this pattern, user requests are routed to a Controller which is responsible for working with the Model to perform user actions and/or retrieve results of queries. The Controller chooses the View to display to the user, and provides it with any Model data it requires.
The following diagram shows the three main components and which ones reference the others:
This delineation of responsibilities helps you scale the application in terms of complexity because it’s easier to code, debug, and test something (model, view, or controller) that has a single job. It’s more difficult to update, test, and debug code that has dependencies spread across two or more of these three areas. For example, user interface logic tends to change more frequently than business logic. If presentation code and business logic are combined in a single object, an object containing business logic must be modified every time the user interface is changed. This often introduces errors and requires the retesting of business logic after every minimal user interface change.
The Model in an MVC application represents the state of the application and any business logic or operations that should be performed by it. Business logic should be encapsulated in the model, along with any implementation logic for persisting the state of the application.
Views are responsible for presenting content through the user interface. They use the Razor view engine to embed .NET code in HTML markup. There should be minimal logic within views, and any logic in them should relate to presenting content.
Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction
What is ASP.NET Core MVC
The ASP.NET Core MVC framework is a lightweight, open source, highly testable presentation framework optimized for use with ASP.NET Core.
ASP.NET Core MVC provides a patterns-based way to build dynamic websites that enables a clean separation of concerns. It gives you full control over markup, supports TDD-friendly development and uses the latest web standards.
ASP.NET Core Architecture
The ideology behind ASP.NET Core in general, as the name suggests, is to lay out web logic, infrastructure, and core components from each other in order to provide a more development-friendly environment. The concept is somewhat similar to “N” tier/layer architecture, the only difference is that ASP.NET Core defines the layers as the core component of the platform which relieves the developer from redefining it in order to make a solution more modular and reusable. What happens in ASP.NET Core is that the main business logic and UI logic are encapsulated in ASP.NET Core Web App layer, while the database access layer, cache services, and web API services are encapsulated in infrastructure layer and common utilities, objects, interfaces and reusable business services are encapsulated as micro-services in application core layer.
So, in essence, ASP.NET Core creates necessary pre-defined “N” tier/layers architecture for us developers automatically, which saves our time and effort to worry less about the complexity of necessary “N” tier/architecture of the web project and focus more on the business logic. In non-ASP.NET Core environment, we as developers are more focused on the business logic and the selection of best design patterns, not on the architecture side because at the end of the day, the final version of our web project is deployed on a single tier machine. We are more focused on managing the complexity of the project in terms of code re-usability and modular components but on a single tier, very few organizations/enterprises actually implement “N” tier/layer architecture to make their product more robust and modular because it requires more resources consumption, management for scaling the project as necessary, and, of course, hiring of more skilled resources who can build the necessities.
No wonder you will find many modern web development frameworks more pre-build design pattern friendly rather than pre-build tier/layer-friendly. Because a developer needs to make the necessary tiers/layer himself/herself and no wonder MVC design pattern is the most popular for web development. Remember that design pattern and architecture are separate concepts. Unfortunately, many senior developers refer to design pattern and architecture as same. So, they refer MVC as architecture rather than a design pattern.