What is the advantage of Model-View-Controller (MVC) over Model-View?

Question

Can someone give an example of why it would be beneficial to use MVC instead of a simple model and just for viewing.

Note: regardless of whether it is called MVC or MVP (Model-View-Presenter), I’m talking about where View receives the input, then the controller will respond to the input event, interpreting the input to any action made by the model. When the model changes, the View will update itself by responding to events from the model.

What is unprofitable just to allow the model to respond to events in the view and vice versa?

In MVC, if I change the model in a way that affects the controller, then I will have to make changes to the controller. In Model-View, if I change the model, I will have to update the view.

So it seems we are introducing complexity by adding the “controller” part?

Answer 1

In MVC, a model is blind to its environment, a view may be too much - passing (blindly) its events to a controller that knows more about the view and model. Therefore, when everything is said and done, the controller is a “one-time” one-time part of the system, since it is the most context-sensitive component.

if I changed the model in a way that affects the controller ...

The model should expose simple CRUD methods in such a way that those who use these methods should not know anything about the past update object, as well as what really happens inside the model.

This means that the view, IMO, needs to do a little work by creating a missing record, because the controllers must be inactive and the view more stable. The controllers start up, and the kick-in does its job with the transferred object and has no state.

Past data is created by some general agreement.

Let me go even further. Suppose you have a view, a tablegrid, and a control whose enabled property depends on the item is selected in the grid - you CAN create a view that handles both these controls and this logic inside, and this will probably be a way to such a simplified example.

But the more atomic your views are, the more reusable they become, so you create an idea for every, yes, every, management. Now you are looking at a situation where opinions need to know about each other in order to register for the right notice ...

Here is the controller, because we want to bind all these dependencies to it, a long-term one-time. Thus, the controller controls this notification type of the view view.

Now your views are ignorant, because they can be independent, so you can reuse them.

You can encode a view without knowing the system, or the “business logic,” as they call it. You can encode the model without knowing too much about your goals (although this helps to set up the model so that it can return the data you have in mind) .... but the controllers, they are the last, and you must have the previous two strengthened before how you can connect things.

Here's something else to think about - just as the model should abstract away and provide a common interface for the basic implementation of the data it manages (the client does not know if the data comes from the database, file, program parameter, etc.) - the view should also abstract from the used control.

So, ultimately, this means that the view should not (below) contain functions / properties that look like this:

public property BackgroundColor{get;set} 

Nor

 public function ScrollBy(x,y){} 

Instead of this:

 public SetProp(string name, object val){} 

and

 public DoCmd(string name, object val){} 

This is a little far-fetched, and remember what I said in the end ... and you ask why this is a good idea?

Given the possibility of reuse, think that you will ever want to transfer things from WinForms, say, to Flex, or just want to use a new management library that may not expose the same features.

I say “port” here, but it’s really not the goal, we don’t care about porting this particular application, but the basic elements of MVC are common enough to be ported to a new taste - internally, leaving a compatible and independent of the external interface.

If you haven’t done so, then when your new taste comes, all your hard links to view properties in controllers (potentially reusable / regenerable / extensible) should be removed.

This does not mean that such universal setters and cmds should be the interface for all your abilities of looks, but they should handle the properties of the "edge case", as well as the usual details / cmds, which you can open in the traditional hard -link. Think of it as an "advanced properties" handler.

So (invented again), suppose you build a frame where your buttons no longer have the buttonIcon property. This is cool because you had the forethought to create a button view interface where buttonIcon is an extended property and inside the view, your conditional code now does no-op when it gets the / get set.

In general, I want to say that the goals of MVC coding should be to provide the basic Model and View interfaces with their basic components, so when you code a controller, you don’t have to think about who you are controlling. And while the Controllers (seemingly unfairly) are determined to be a sacrificial lamb in the long run for reuse, this does not mean that all your controllers are designed to die.

They, hopefully, are small, since many of their “thoughts” were thrown into semi-intelligent Models and Views and other controllers (for example: A controller for sorting a grid or manipulating a TreeView) - therefore, being small, they can be easily viewed and qualified for reuse in your next project - or cloned and modified to become suitable.

Answer 2

In fact, this reduces complexity by separating workflow logic from domain logic. It also simplifies the writing of unit tests and simplifies their support and expansion.

Imagine if you want to add a new data type. Using the above approach, you are likely to duplicate a lot of the workflow logic in the new class, as this is likely to be closely related to the domain logic.

The discipline involved in dividing the workflow logic into a controller makes it more likely that you will have fewer dependencies between the workflow and the domain logic. Then adding a new data type will be easier, you will create a new domain object and see how much of the controller you can reuse, for example. inherited from the superclass of the controller.

It would also facilitate the change of frameworks in the future - the model probably would not change too much and therefore would be more portable.

Having said that, you can look in MVVM depending on what you use as the presentation level: Advantages of MVVM over MVC

Answer 3

Advantages of MVC / P (I mean Supervising controller here) over MV:

• If necessary, you can process complex data binding code in the controller.

• You can test this complex presentation logic without the need for user interface testing.

• You can also have a graphic designer who will do your looks, and not see your code, and not ruin your code when they correct your views.