Imagine an application where the user is allowed to create his/her own musical scales. The user selects notes from a list, arranges them to a group and presses a button to create the scale.

In an MVC structure, upon pressing the button, the View would tell the controller "the user wants to create a new scale, here are the names of the notes" (passing an array of strings).

These names need to be interpreted into the matching Note objects, before they are composed into a new Scale.

The question is, should this interpretation happen in the Controller, before passing a Notes array to the Model where the Scale creation will take place? Or should the Controller just pass the array of strings (representing the names of the notes) along to the Model, where the Model will interpret the names to Notes and compose the Notes to a Scale?

What would be more conceptually correct, according to the idea of MVC?

  • It really depends on whether you like to keep your models dumb or not. I personally like to keep the models as simple as possible (properties only) and have either the controller or another entity (such as a notes service) handle the domain or business logic. This keeps the View, Controller and Model simple. If your not doing a service layer then you should keep reusability in mind. MVC is thrown around as a high level separation of the model view and controller...but the rest is really dependent on your needs and preference. Sep 14 '14 at 14:15

Interpretations like the one from a string representing a note to a note object is the very reason for a controller, and therefore should be placed there.
The underlying idea behind the Model-View-Control pattern is to maintain a domain model free of system details. This separation of concerns allows the model to focus on the domain only and let surrounding components connect the model with the rest of the system. The responsibility of the view is to translate the model into a visual representation, and the responsibility of the controller is to translate user (or system) input into the language of the domain.

  • I see... So for example hypothetically later on I might be interpreting recorded sound into Note objects, or images. But that will always be the work of controllers, the model only knows about the 'pure' domain, which is about Notes. Makes sense :) thanks
    – Aviv Cohn
    Sep 14 '14 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.