I've been trying to understand this model for a time now, but I don't really get it. I've seen that picture everywhere with model - control - view and yadda yadda. I understand the concept, but I don't get the thing with observers and stuff. I've tried to look at simple examples, but they are not simple enough for me I feel.

Can someone make an EXTREMELY short example of this in just a couple of rows? I don't want to have any details to make it perfect and those kind of stuff. Maybe you can just give me an example of how to change a String name = "xxx" and to change it to "yyy" with the control class file.

I want it as easy as possible and ignore every detail that makes it better and that kind of stuff. Just a basic understanding would be super! (a working code of course).

I would be very happy if someone could help me with this!

Thanks in advance!

Generally ignore the concept of observers.

The general gist is you have...

A model: which is a representation of the data

A Controller: Tasked with manipulating the data and applying logic to the data

A View: Tasked with displaying the data.

So you may have a model called ProductList. It stores a bunch of products.

The controller would contain methods to say add a product or remove a product and a method render the appropriate view

The view would display the data and possibly allow interaction with the controller.

Essentially you are creating a chain of command. You see the data with the view and you use the view to tell the controller what you want. The controller is the middle man between the view and the model to ensure everything done to the model is done properly. The goal is to create a layer of separation between your data, data logic, and visual data representation.

Bringing Observers into it just complicates the understanding and I feel it is not really necessary.

That was a quick answer! Thank you!

Could you maybe give a very simple code example of your idea about the ProductList? :)

Generally it may look something like this crappy psudo code

Class ProductList

Products[]

Product GetProduct(ProductID)

Class ProductListController

prodlst ProductList()

AddProduct(Product)

RemoveProduct(Product)

// some other methods

RenderView(Filters)

// various view classes based off of filters to modify and customize the output

Wish I could give something more robust but I tend not to use MVC as I feel it is an over abstraction for most problem scopes that will get you into trouble. The most use I have seen for MVC is in web software.

A model: which is a representation of the data

A Controller: Tasked with manipulating the data and applying logic to the data

Although this is a common interpretation, this is not the original meaning of the model and the controller. The original meaning would be more like this:

• Model: a representation of the data and the logic to manipulate it
• Controller: translates input requests from the user into calls to manipulate the model

In other words, the Model handles all the important parts, the View is the output, and the Controller is the input.

The danger of having a controller "tasked with manipulating the data and applying logic to the data" is that responsibility for the correct use of the data is now split across 2 separate groups of objects, controllers and models. You have model objects that are barely more than just clumps of data and you have controller objects with implementations heavily coupled to those clumps of data. Why not just concentrate that information in the model, which then can provide a minimal interface for the controller to use when the user sends some input?

Maybe it'll help to explain it differently:

A Model is a collection of data and the structure of that data. A couple of examples: say you have a list of names in a text file. The names is the data, the fact that each name is on its own line in the text file is the structure. The more obvious example is a database: the entries are the data and how the tables are set up and connected is the structure.

A View is the UI and how the data is presented to the used. This is the buttons and rows and other visual elements that show up on the screen, along with the code to pass input on to the controller. Think dumb terminal; the View doesn't know what the data is, it only knows that it's going to display 10 rows of something it recieves from the controller and if the user hits the next button, it should tell the controller about that.

A Controller is what parses the data from the Model and prepares it for the View. It's the middleman between the View and the Model. The Model doesn't care how it's data is presented or even if all the data is used, it's fairly passive. The View doesn't care what the data is, only what fonts or screen regions are going to be necessary to show it. The Controller is what takes the View's input, finds the appropriate data in the Model, and gives it back to the View. The Controller is like a waiter; you (the View) point to an item on the menu, and the waiter gets that item from the kitchen (the Model). You don't care how it was made in the kitchen or what sort of maze the waiter went through to get the dish; you only care that the correct item was given to you.

The Controller is seperated from the Model because you should be able to change the data without affecting how you retrieve/filter it. The View is seperate from the Controller because retrieving/filtering data has no affect on HOW it is presented, only WHAT is presented.

To use a more concrete example:

This is a screenshot from PokeIndex 5th Gen, an app I made for iPhone. The Model in this case is a literal database with the Pokemon's number, name, and filename of the image. The View is a table view: it doesn't know or care what Oshawott is, only that it has to display a 32x32 image, format a 3 digit number with the Marker Felt font at 20 point size, and do the same for a text string. It also has to be pass to the controller a message if any of the rows are tapped. The Controller handles loading the Pokemon info from the database, filtering it (by Pokemon number in this case), and preparing the info in a way the View can use.

I could change the Model to use Pokemon X and Y instead of Black and White and that won't affect the Controller. I can change the View to display a grid of Pokemon instead of a list and that won't affect the Controller. This is the encapsulation that the MVC pattern is designed for. But unless you have a certain degree of complexity in your Model (in this case, it's 650 Pokemon with all thier stats and locations), then the MVC pattern is over abstracting, as blewisjr said. If your View has constraints that keep it from changing, MVC may not be the best solution either.

That said, the iOS libraries push the MVC pattern pretty hard, so that would be one way of immersing yourself in it.

A Controller is what parses the data from the Model and prepares it for the View. It's the middleman between the View and the Model.

The Controller knows both about the Model and the View. If you click on the "fire" button on the mouse, the Controller knows what Fire function in the Model to call. If you press the button for switching between first and third person, the controller knows what function in the View to call to request the change.

Without wanting to labour the point too much, these are both reasonable architectures to use, but they aren't what the original MVC was designed for.

Originally, the View would access information from the Model directly. For example, the model has a FullName() accessor, which the view calls to get the full name, and the view calls that function to get the string of data that it needs. So you might ask, how does the view know when to call the accessor? Usually the view is an observer, waiting for an update notification. Or the controller might be able to provide notification of an update directly. But the controller shouldn't - in the traditional system - be providing the data directly. That would increase the coupling between the parts of the system and make them harder to change. The Controller shouldn't need to know what information the View needs: eg. some views might only care about the LastName, some might care about the FirstName - if a controller asks to change the FirstName, what name information should it pass to the View? What if that View only cares about the LastName? The best answer is to let the View know that something has changed, and let it figure out for itself what information to query.

On the second example, if you actively change the whole View, that's something a bit out of the scope of the original MVC. Arguably this is when you need a "Presentation Model", which is sort of a Model for the View itself! This is one of the shortcomings of the original MVC system as it can't really handle this sort of change. This is probably why a lot of systems now have variations on MVC, like MVVM or MVP, because the original idea of MVC is both misunderstood and not always suitable for modern apps.

Good reading, although possibly a bit dense:

http://martinfowler.com/eaaDev/uiArchs.html#ModelViewController

http://martinfowler.com/eaaDev/PresentationModel.html

Thanks a lot for the information in this thread. Though I still don't really get it because I need some kind of code example I think. One proper example that will work which I could fiddle around with and play and try and understand :)