The point of MVC - model-view-controller

Question

First, just to say, this is not a troll posting, I'm genuinely completely and utterly at a loss as to why MVC is where the industry is going/gone. If MVC wasn't on every job advert I've seen for the last 4 years I'd not bother but as it is, it looks like I'm going to have to use it.
What is the point of MVC? Yes you get the pretty URL e.g. www.amazon.co.uk/books/horror/ but I can't see any other advantage. I was reading the ScorrGu blog where other's where asking the same
https://weblogs.asp.net/scottgu/introducing-razor
This is the copy+paste reasoning from the ScottGu blog concerning Razor
Some people like a controls model with code-behind for code/content separation, and others like a MVC model where there is separation between the controller and view. In an MVC model your application/business logic is contained within the controller and model layers - and does not live in your view. Your view file instead just focuses on generating HTML rendering.
In the controls model there is "separation between the controller and view" in that there is the code behind(controller) and the content (view).
Application/business logic is sprinkled throughout the view (depending on what's on that view obviously) from the examples and tutorials I've been looking at logic like "Does this user have permissions to see this link?"
"Your view file instead just focuses on generating HTML rendering."
It isn't
#foreach (var item in Model.Items) {
var style = item.IsArchived ? "archived-validation-item" : "";
#Html.DisplayFor(modelItem => item.Code)
their is logic here about how many times a loop is performed and retrieving the right item code.
In the controls model, a page has two files one containing the logic and one the layout.
In MVC, a page has three files, the controller and model containing logic and the view which contains layout and logic.
The reason classic ASP was left behind was so that the code and the markup were seperated, the front end developer could get on with making it look pretty while the back end developer worked on getting the right things onto that page. Their roles and responsibilities were clear and seperate. With MVC, both developers must know about the model (and viewmodel too if that's used) as well as the view and controller (as well as the routes, etc.) so that everything is linked up together. From the examples I've seen for example, the decision on when a link should be shown could be made by the view, the controller or the model. This adds layers of complexity and confusion.
What am I missing apart from some well paid jobs? ;)
Thanks

Answer 1

You are correct in that the old *.aspx + Code-Behind Class was an example of separating concerns and logic - however it was not true MVC separation because the code-behind class was still concerned with aspects of presentation, and similarly it's possible for the .aspx file to have business logic in it, as an example, this:
ASPX:
<!-- this data-source is arguably a piece of business logic in the view layer: -->
<asp:SqlDataSource runat="server" id="ds1" selectCommand="SELECT * FROM someTable" />
<asp:GridView runat="server" id="gv1" dataSource="ds1" />
<asp:Literal runat="server" id="lit1" />
Code-behind:
void Page_Load(Object sender, EventArgs e) {
this.lit1.Text = "<div class=\"something\"><p>some HTML goes here</p></div>"; // this is presentation logic in the code-behind
}
In MVC separation, you remove the "tight-coupling" between the two, as well as enforcing the separation of concerns because you cannot (feasibly) generate HTML from within a Controller Action, and similarly you should not be able to execute business rules in a View because for example, all database connections are closed at that point in the request lifecycle.
One core tenet of MVC is the "view-model" which is a class that encapsulates the entirety of data represented (and manipulated) by the view (alternatively, the tuple of the ViewModel with the ViewData). As this class is well-defined it means the page is almost self-describing, there is no need to manually examine the view to see what's going on and what data is being displayed.
In summary, it's this:
WebForms:
[query database] -> [populate view directly]
MVC:
[query database] -> [populate viewmodel] -> [view renders viewmodel]
One advantage to this approach is that you can turn a website into a web-service by only changing one line of code:
From this:
public ActionResult Index() {
IndexViewModel viewModel = new IndexViewModel();
// (populate ViewModel here)
return this.View( viewModel );
}
To this:
public ActionResult Index() {
IndexViewModel viewModel = new IndexViewModel();
// (populate ViewModel here)
return this.Json( viewModel );
}
You can't do that with WebForms :)

Answer 2

You can write good code, or bad code independent of the frameworks involved. IMHO MVC is a pattern that better lends itself to test-ability due the view separation. Putting logic in the correct places is still the responsibility of all the team members. MVC won't guarantee a great architecture.
And honestly if your application is correctly designed and your webforms are all calling logic in services, maybe MVC isn't that big of a deal for you personally. Also, I agree with what Vincent mentioned about the shift toward SPA's. Personally I've seen several applications written as spas that aren't interactive that would have been just fine as MVC apps. As always, "It depends" is still the best software dogma.