I'd like to ask a simple controller design question regarding the MVC
pattern. It seems that most of the tutorials follow the
one-controller-per-table pattern. Books like AWDWR however use more
advanced approach. Unfortunalty AWDWR doesn't provide an answer how to
choose how many controllers to have and what methods to be included.
My question is how do you choose how to break the logic into controllers
and how you solve cases when the process is not oblivious (for example
if you have
two controllers using the same model).
I'd like to ask a simple controller design question regarding the MVC
pattern. It seems that most of the tutorials follow the
one-controller-per-table pattern.
Could you cite one? That's not MVC. An MVC Controller is like an old-fashioned telephone operator, with a patchboard and a bunch of cabled plugs. The operator plugs any set of models into any set of views.
> Books like AWDWR however use more
advanced approach. Unfortunalty AWDWR doesn't provide an answer how to
choose how many controllers to have and what methods to be included.
My question is how do you choose how to break the logic into controllers
and how you solve cases when the process is not oblivious (for example
if you have
two controllers using the same model).
Write unit tests for everything, and refactor early and often.
When you refactor, obey the "DRY" principle. (Don't repeat yourself.) Merge any shared code together. So two controllers using the same model will call the same methods on it.
That’s an unfortunate side-affect of the way MVC in Rails is presented. Controllers only contain flow logic. They handle requests and deliver responses.
Models have a 1:1 relationship with tables, but models can also be table-less.
Models should contain your business logic. Saving, calculating, validations, etc. Controllers should do nothing but pass requests to models and render views. If you find yourself doing anything more than that in a controller, then you’ve got refactoring to do.
