MVC Redefined in Onion Architecture

Originally MVC was defined to small UI Controls. It was defined for UI toolkits. How UI tool kits should work. It was not defined as the Application Architecture.

MVC is design pattern to structure the View Layer or UI Layer.

MVC is a design pattern to define SOC and balanced distribution of responsibilities  within the View Layer.

The Definition  or understanding of MVC in the Onion Architecture is different.

Views are à Cshtml files holding html markup

Controllers è Asp.net mvc controllers

Models è ViewModes needed by the View. Clean architecture says them RequestModel, ReponseModel or ResultModel

MVC totally resides on the outer layer of the Onion Arch, Hexagonal Arch, and Clean Arch

MVC has nothing do with Application Layer and layers below that

MVC’s Model == ReadViewModel or WriteViewModel

MVC’s Model == QueryViewModel or CommandViewModel

MVC’s Model  !=  Domain Model

MVC Components == View Layer that is replaceable

View Layer è Application Service Layer

MVC == Views + Routing Engine + Controllers + ViewModels + Presenters

ViewLayer == Views + Routing Engine + Controllers + ViewModels + Presenters

ViewModels are defined inside the Application Service Layer because View Layer include Application Service Layer not the vice versa.

All stuff outside the Use Case Layer or Application Service Layer is the VIEW LAYER and should not be subjected to testing.

Views should be light without any Application Logic and Business Logic so that there is no need to test them.

On the higher level only Applications Services should be tested.

Application Service == Use Case Layer

Application Service and Below should be tested and they must be testable

As Views + Controllers + ViewModels are not needed to be testable, these is not need to have Interfaces between Controllers and Applications Services. There is no need to Inject Application Services to the Controllers. There is no need to have DI/IOC for injecting Application Services to the Controllers. i.e. Contollers can hard reference the Application Services.

Command

View è Routing Engine è Controllers (WriteViewModel) è Application Services ====

Queries

View ç Presenter ç Controllers (ReadViewModel) çApplication Services ====

ASP.NET MVC Controllers   !=   Applications Services

Web API Controllers   !=   Applications Services

Presenters are objects to annonate the Read ViewModel with the UI specific logic or transform he ReadViewModel data to the format that is required by the View.

Views only take data from ReadViewModel and display on the View.

Views should not contain any Routing Logic, Application Logic, Business Logic

Routing Logic is buried inside the Routing Engine in asp.net mvc

Controller still has responsibility to get the data from request and package them into the ViewModel

Controllers should be thin and only contain Routing Logic

Controllers should not contain Application Logic

ReadViewModel is completely oriented towards the View. For example it cantain Flags to enable disable the UI elements. It contains formatted data thas suits to the UI controls.

WriteViewModel is complete oriented towards fetching the Data from the Request and passing it to the Application Service.

Uncle Bob RequestViewModel and ResultViewModel or ReposneViewModel are telling story of CQRS by Greg Young.