question about the mvc pattern

i dont quite understand this pattern.

from what i have read, it looks like one model = one table (if you are using database to store data).

so if i've got a table called tags, i should have a tags model. and with a threads table i create a threads model.

then i got a tags controller and a threads controller right?

so what if i've got a tags_threads_map table for a many-to-m开发者_运维技巧any relationship.

should i have a tags_threads_map model eg. in which i get all threads containing a tag? should i have a tags_threads_map controller too?

would be great if someone could explain or give me a good breif tutorial on this.

the most tutorials just give a simple 1:1:1 example.

To fully understand MVC or any software design pattern, you really need to have a go at implementing it and see what your results are.

That said, MVC does not prescribe that one model = one table. In fact, a model could be backed by a number of tables, or even data originating in something other than a relational database (e.g. a web service, flat files, a key-value store or a graph database for example).

I would suggest that creating models and views that represent meaningful aggregates of related tables is probably a good approach. For example, to use the timeworn example of an Order and OrderLine table, an Order model might encapsulate operations on data that will ultiamtely end up in either the Order table or the OrderLine table.

Adhering to strict 1-to-1 mapping of table to Model, View and Controller will only result in an explosion of classes, some of which may not be doing much individually. Better to build Models and Controllers that are more focused on achieving some task identified by the business requirements, rather than just being a projection of the data model.

So the idea is less "one model = one table" and more that you don't want code that manages the data to be interleaved with code that manages the operations on data or code that handles user interaction. If you have some sort of persistance layer that handles mapping of objects to a database, that's enough to have a rudimentary model. If you have some separate code on top of that that does something algorithmic with that data, that's a controller. If you have a way of rendering the data for user consumption, that's a view.

Best example that comes to mind is a spreadsheet: the data in the spreadsheet is your model. If you have expressions in your sheet that manipulate the data, that can be seen as a controller. If you see the data in tabular form, or in a graph, those are two views. The views don't muck with the data or how it's calculated - they format it for your eyes. The controller doesn't format the data for your eyes - it creates / changes / calculates the data. The important part is separating out the concepts so you can, for example, write algorithms that don't care how data is stored, and views that don't care how data is calculated.

In my opinion, it's better to think of a model as a model of an object type, not of one specific table.

Generally, your MVC framework would handle your many-to-many relationships by definitions from within the models for tags and threads.

And you definitely don't need a controller for every model; controllers are generally more closely related to views (though there are usually multiple views to one controller).

This seems like it's too general of a question to be able to be answered to your satisfaction here.

A model can be more dynamic than that. For example, if you have a blog, and a blog has tags, your model might be called Blog and it can have a collection of Tags.

A model can be anything that stores the data. In the web app I'm working on there are several tables for contacts, their addresses which groups they belong to and so on. It's probably best to split them up by types, I should have made a group model but you don't strictly have to do this.

MVC relates to 3d games quite well, MVC is not only for information systems. Consider this: In 3d graphics the model is map, the polygons and their positions and colours. The view is the camera from which the scene is viewed, a position, zoom and direction. The controller interprets the keyboard and mouse and manipulates both the camera(view) and scene(model).

If this were a shooter game then if: A user pushes the forward button, the controller moves the camera forward. A user pushes the throw grenade button, controller adds a grenade to the scene.

The view is presentation, the model is storage/structure and the controller is an in between which tells the view what to display and how to display it based on the state of the system.

Generally you put all the formatting in a view, data in models and logic into controllers.