0

I am trying to introduce some good practices into my website coding, so I started to look into MVC, since it is a buzzword in website designing :-) I am confused by the MVC pattern though. I am used to thinking in a Three-tier pattern, where you have 3 layers:

  • presentation
  • logic
  • data

Two things confuse me around MVC:

  1. "Model" component is often presented as the data layer above (database abstraction). But where does the "high-level" logic belong to? Like deciding what you will do with the data and how, checking permissions etc. Sometimes I've seen some of this in the controller, but it is really confusing for me to decide which belongs where.

  2. The MVC pattern is presented as a circle of 3 components which send messages to each other, like M -> V, V -> C, C -> M, and the other way around. I understand perfectly the Three-tier design, where one layer calls the layer below itself, but not the other way around! The functions in your programming language can call other functions (you can call it "sending a message") - but it is an oriented tree graph. But how can the lower layer, or, how can the called function "send a message" or "notify" the calling function?

Maybe I am too much concerned by the MVC pattern and could happily stay with my Three-tier designing? Anyway, I would like to understand MVC pattern to at least see if it is worth using for me.

Tomas
  • 57,621
  • 49
  • 238
  • 373
  • See if this explanation helps you - http://www.intstrings.com/ramivemula/articles/asp-net-mvc-high-level-architecture/ – ramiramilu Feb 17 '14 at 13:06

1 Answers1

0

The model is another way of saying your domain knowledge, your controller should be deciding what models to display, update, create, and your view should just present the data the controller has decided to present. To address your second question the model is normally passed to the view through the controller to the view for the data to be presented.

For more details scroll down the the Model View Controller section of this page

PlTaylor
  • 7,345
  • 11
  • 52
  • 94
  • *"your controller should be deciding what models to display, update, create"* - this means that you put all the high level logic to the controller - since it must decide if something has to be created, or updated or .... For most sites this logic is quite trivial, but for my application this will be a non-trivial logic. So, as you explain it, the model is just a pure "database-layer" and "data-to-be-dispayed" content? – Tomas Feb 17 '14 at 12:59
  • You know your domain significantly better than I do. In my case a lot of the time the model has a lot of calculations and logic that aren't trivial, but that is inherent in my domain. If the logic to decide which object to push to the page is non-trivial then it is non-trivial and you should be happy that controllers are just as easy to test as models are. The only time I get concerned is when people say their View has logic that is non-trivial. That is a red flag for me. Read the Fowler page and concrete the ideas in your head, but having non-trivial controller logic is not a problem. – PlTaylor Feb 17 '14 at 13:05