Hello! 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). Thanks -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Winter Mute wrote:> 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. -- Phlip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model sums it up nicely. On Mon, Mar 3, 2008 at 12:50 PM, Winter Mute < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Hello! > > 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). > > Thanks > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Mar 3, 2008 at 1:19 PM, Brian Hogan <bphogan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> That''s an unfortunate side-affect of the way MVC in Rails is presented. >Sorry, that should have read "That''s an unfortunate side-affect of the way MVC in Rails is presented in many books and tutorials." My apologies. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Winter Mute wrote:> Hello! > > 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). > > ThanksModel should have all the business logic. In fact, ideally that''s where most of code should be..the model. Controller is just like a control center that bridges between model and views. Ideally it should just have the CRUD (Create, Read, Update, Delete) operations. Views is all client side presentation stuff. Putting most of the code and business logic in the model also isolates it from the views...that''s desired.. So, bottom-line controller should have the minimum code. Watch DHH''s railsconf keynote on Rails 2.0 RESTful architecture. http://www.scribemedia.org/2006/07/09/dhh/ Be sure to download the pdf before you watch it. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---