What Is MVC and Why Do We Use MVC?

What is MVC? Why use MVC? It's a very vast topic to explain. I will explain what MVC is. It’s just a three layer architecture where M stands for MODEL, V stands for VIEW, and the most important part in this architecture is CONTROLLER, like a Hero of any film. Thus, every layer in MVC is assigned with a unique responsibility. So, the View is for the look and feel as well as for positioning what the end user will actually see. The model supplies the data and business logic. So, the models are nothing but just a class, like employee, student etc. and a model can interact with the data access layer, some kind of service, like WCF Service or Web Service, which gives the data. The controller is actually the heart of MVC and as I mentioned above, like a film Hero, it deals with both the layers. This is why the controller is also called the coordinator between the Model and View.
 
 
In MVC, if a user sends the request from the Web Browser, it first comes to the controller. Controller sends it to the appropriate View. The data request goes from the user and the controller goes to the model class because model always carries data, as already mentioned. If we change one layer, all the other layers remain intact. This is the major advantage that makes MVC perfect. Here, the second diagram explains one controller folder with the extension of the files with the controller, which also has a Model folder that has your customer's class supplier.
 
 
When an end user sends an action like Add Customer, update customer, go to home or whatever, it first comes to the controller. If the controller says OK, let me search for the appropriate model for it, it then returns it  to the View. In the third diagram here, the view layer can be a ASPX View or Razor View, or Engine View, which is mostly used in MVC architecture. After searching the appropriate Model, go to the controller. Now, it is the controller's responsibility to send the information that comes from the Model sent to the View, which can be Razor View or ASPX View as these are the advantages of the three layer architecture. A user, now, has more flexibility.
 
 
Now, let's talk about why MVC? Why is MVC more reliable than others, like Web forms? Let's discuss why only MVC does not have Web forms. Let's have some background approaches of ASP.NET. This image will explain more scenarios of the difference between MVC and Web forms. Let's view it.
 
 
Let’s start with Windows background, about Microsoft at the start. Microsoft introduced it with the word visual and Microsoft wanted the same success story as Windows used in programming a lot of languages like COBOL, C++, and DB’S. All these languages do not have any Visual effect, so if you want to fix a button in C++, actually you have to write the code for it. Thus, Microsoft ventured something called Visual programming or RAD programming (Rapid App development), so they set that for this, rather than programmer code for this, so  for creating a window Microsoft introduced tool box. Due to this, they launched Visual Studio and again in programming language, Microsoft got success. At that time, power builder was to be completely replaced by VB, like VC++ was replaced by C++ and VF (Visual FoxPro) almost killed it and it replaced DB so Microsoft achieved success.
 
 
The RAD programming is great but it leads to some issues  -- the issue is at the backend of the code. In other words, when the programmers drag and drop, the code is generated in partial class. Let's discus some of the drags of this RAD programming:
 
Problem no 1: View Based architecture for an Action Based requirement.
If user sends an action, what happens in the page life cycle is that the  life cycle just calls a complex structure, and the page loads the page in,  and you know what other kind of life cycles get executed, and then runs the required event. Now it’s a really complicated method. What should happen is  this is a required event, not one that runs other events. So what happened in this scenario when the end user sends a request as an action is it then goes to the View first, and again runs a complicated life cycle. In other words, you go to the complicated life cycle, but the  logical approach should be to go to action directory; that means once the user sends the action request it should actually map to a method inside the program, and  the method gets invoked, runs all the necessary logic for the action, and then it's invoked the required view and that would actually happen in  MVC.
 
Problem no 2: Behind code is not reusable..
So the connected problem for selecting bad architecture was that the behind code was not reusable so the RAD architecture is not usable but in MVC we can code reusable code again and again.
 
Problem no 3: Html is not the only response type.
Mostly the web pages are on HTML but in case of xml if your application is communicating with languages like JavaScript, probably its sends it to Jason then you would like to invoke the action but the action can have different kinds of response types depending on the situation.
 
Problem no 4: Flexible combination of view+data
So Web Forms is a View based architecture  -- always view has been decided but in the case of MVC what happened is it first hits to controller so the possibility of combining is more in the case of MVC but not in the case of Web Forms. Why? Because the view always fixed. 
 
Problem no 5: Behind Code
We have easy way of unit testing  in MVC, which  is the option of a Unit test after creating a new project but in the web it would quite difficult to handle.
 
So the solution of these problem is the simple structures, just MVC in this diagram, the first line shows RAD or WEB FORMS architecture which will be in the form of aspx which is divided into two parts --  one is view and the other is behind code which is called the middle layer, which has the business logic and this logic calls the DAL data access layer. The problem is the first time it comes in the view. But in MVC its behind code is controller and first receives the request and then sends to the view and model as mentioned in the diagram.