4 ms·

I run into this question frequently: how much logic belongs in the controller, and how much in the model. The difficulty, I think, is that every method you add

by aphyr 16y ago

I run into this question frequently: how much logic belongs in the controller, and how much in the model. The difficulty, I think, is that every method you add to the model requires a name, and the profusion of names leads to complexity and poorly named methods. An alternative is to collapse similar methods (for example, two queries differing only by "order by") into one, and use a parameter or function argument to distinguish the cases. But this pushes ORM-specific logic back up into the controller--only now with an extra layer of indirection for the programmer to remember how to use. My approach has been to define methods on the model only when they are used in more than one place or have a concise, meaningful name. Introducing the abstraction later rarely requires modifying several aspects of the application, and Sequel's def_dataset_method/chaining approach make this relatively painless.

Xurinos 16y ago
> how much logic belongs in the controller, and how much in the model I always thought this was really simple (at least based on the original Xerox definition of MVC): Controller transforms inputs/parameters as needed. Controller can use Model to do this. Controller creates/manages views and sends latest data to the Views. And a confusion-reducer: Controller is not between Model and Views. Views have direct access to Model. It ONLY uses Model to figure out the situation. I have found these clear separations helpful in a variety of applications. I have also found that people that apply MVC to the web confuse themselves, too. On the server side, your View is what you are returning to the browser. JavaScript is part of the View of the server. It has its own MVC when it is run in the browser environment, and the browser has its own MVC. It is perfectly acceptable to have interlocking components, each with their own MVC.
- mononcqc 16y ago
  A note: The architecture model where the controller sits between the model and view is instead called 'Model-View-Adapter (http://en.wikipedia.org/wiki/Model-view-adapter http://en.wikipedia.org/wiki/Model-view-adapter), where the controller (or adapter) is doing the mediation between the model and the view. It supposedly allows for a stronger separation of concerns.

by aphyr 16y ago

Xurinos 16y ago

> how much logic belongs in the controller, and how much in the model I always thought this was really simple (at least based on the original Xerox definition of MVC): Controller transforms inputs/parameters as needed. Controller can use Model to do this. Controller creates/manages views and sends latest data to the Views. And a confusion-reducer: Controller is not between Model and Views. Views have direct access to Model. It ONLY uses Model to figure out the situation. I have found these clear separations helpful in a variety of applications. I have also found that people that apply MVC to the web confuse themselves, too. On the server side, your View is what you are returning to the browser. JavaScript is part of the View of the server. It has its own MVC when it is run in the browser environment, and the browser has its own MVC. It is perfectly acceptable to have interlocking components, each with their own MVC.

mononcqc 16y ago
A note: The architecture model where the controller sits between the model and view is instead called 'Model-View-Adapter (http://en.wikipedia.org/wiki/Model-view-adapter http://en.wikipedia.org/wiki/Model-view-adapter), where the controller (or adapter) is doing the mediation between the model and the view. It supposedly allows for a stronger separation of concerns.