Fellow Railers, Is there anything, anywhere, that I can read that discusses overall RoR app design? I have the Agile RoR book, which is great for learning the details of RoR, but unfortunately doesn''t cover the overall issue of creating a large, complex RoR app. My staff and I are still in the process of getting up to speed on Ruby and RoR, but we also need to begin thinking about the best approach to converting our very large and complex Win32 (Delphi) DB app over to RoR. For (simple) example, our app currently has 42 DB tables. Would it be considered bad design in RoR to have 42 separate controllers, or should we create one generic controller that handles all the basic CRUD for all the tables? I believe there are some new RoR books coming out later this year, which may help, but we could really use some help *right now*. Thanks to all who respond! P.S. I see that the 37Signals guys are putting on a workshop where they discuss things such as big-picture design. Sounds like maybe something I should attend... -- Posted via ruby-forum.com.
This is a good question. You probably don''t want one controller for each table. I thought of my app in terms of the major objects that get operated on, and created a controller for each. That ended up being 3, for about the same number of tables you have. For a manufacturing app, for example, you might have controllers for Jobs, Components, Bills of Material, Equipment, etc. The way the scaffold is set up is pretty quickly left behind. On 1/31/06, Peter Jagielski <pjagielski@gmail.com> wrote:> Fellow Railers, > > Is there anything, anywhere, that I can read that discusses overall RoR > app design? I have the Agile RoR book, which is great for learning the > details of RoR, but unfortunately doesn''t cover the overall issue of > creating a large, complex RoR app. > > My staff and I are still in the process of getting up to speed on Ruby > and RoR, but we also need to begin thinking about the best approach to > converting our very large and complex Win32 (Delphi) DB app over to RoR. > For (simple) example, our app currently has 42 DB tables. Would it be > considered bad design in RoR to have 42 separate controllers, or should > we create one generic controller that handles all the basic CRUD for all > the tables? > > I believe there are some new RoR books coming out later this year, which > may help, but we could really use some help *right now*. > > Thanks to all who respond! > > P.S. I see that the 37Signals guys are putting on a workshop where they > discuss things such as big-picture design. Sounds like maybe something > I should attend... > > -- > Posted via ruby-forum.com. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > lists.rubyonrails.org/mailman/listinfo/rails >-- "Her faults were those of her race and sex; her virtues were her own. Farewell, and if for ever - " -- "Travels with a Donkey in the Cevennes" by Robert Louis Stevenson
I would infact group those controllers in modules For example app/controller/blog app/controller/forum On 1/31/06, Ian Harding <harding.ian@gmail.com> wrote:> > This is a good question. You probably don''t want one controller for > each table. I thought of my app in terms of the major objects that > get operated on, and created a controller for each. That ended up > being 3, for about the same number of tables you have. > > For a manufacturing app, for example, you might have controllers for > Jobs, Components, Bills of Material, Equipment, etc. > > The way the scaffold is set up is pretty quickly left behind. > > On 1/31/06, Peter Jagielski <pjagielski@gmail.com> wrote: > > Fellow Railers, > > > > Is there anything, anywhere, that I can read that discusses overall RoR > > app design? I have the Agile RoR book, which is great for learning the > > details of RoR, but unfortunately doesn''t cover the overall issue of > > creating a large, complex RoR app. > > > > My staff and I are still in the process of getting up to speed on Ruby > > and RoR, but we also need to begin thinking about the best approach to > > converting our very large and complex Win32 (Delphi) DB app over to RoR. > > For (simple) example, our app currently has 42 DB tables. Would it be > > considered bad design in RoR to have 42 separate controllers, or should > > we create one generic controller that handles all the basic CRUD for all > > the tables? > > > > I believe there are some new RoR books coming out later this year, which > > may help, but we could really use some help *right now*. > > > > Thanks to all who respond! > > > > P.S. I see that the 37Signals guys are putting on a workshop where they > > discuss things such as big-picture design. Sounds like maybe something > > I should attend... > > > > -- > > Posted via ruby-forum.com. > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > lists.rubyonrails.org/mailman/listinfo/rails > > > > > -- > "Her faults were those of her race and sex; her virtues were her own. > Farewell, and if for ever - " > > -- "Travels with a Donkey in the Cevennes" by Robert Louis Stevenson > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > lists.rubyonrails.org/mailman/listinfo/rails >-- Rgds, --Siva Jagadeesan varcasa.com My First Rails Project. Powered by Typo and soon by RForum too -------------- next part -------------- An HTML attachment was scrubbed... URL: wrath.rubyonrails.org/pipermail/rails/attachments/20060131/491036b9/attachment.html