I am working on a reasonably large application (which happens to be my first with rails). I was hoping to get some input on organisation of controllers and actions. I am finding having used scaffolding more at the beginning my controllers tend to be very model centric, in that they mostly contain all the actions for management of that particular model, which may crash across multiple use cases. I find this effective in the sense it keeps related actions together. However I am wondering whether it makes more sense to split more administrative actions out into a separate controllers? I imagine this could be a matter of style, experienced MVC developers mixing the two. However any comments on the people''s experience would be much appreciated. --- I also have a question regarding menu pages, I have many maintenance actions that I wish to group into a section of the application. I was thinking of having something like DashboardController with actions such as ''maintenance'', ''warehouse'', ''accounts'' etc. These would contain views with links to major controllers and actions specific to that area of work. This seems reasonably ''tidy'', however has anyone tackled it differently? Thanks, Andrew. -- Posted via http://www.ruby-forum.com/.
I usually mix it up for relatively larger projects, with more preference to use case centric. When authentication and authorization is implemented, it''s much easier to put all related secure actions into one controller instead of having them scattered throughout the different unrelated ones. Still, this is based on instinct and I don''t have a formal decision process for it. I''d like to hear what others do too. "Andrew Edwards" <andrew@shavers.co.uk> wrote in message news:c5bdf3b00be3881586a3d8c9b02146cb@ruby-forum.com...>I am working on a reasonably large application (which happens to be my > first with rails). > > I was hoping to get some input on organisation of controllers and > actions. > > I am finding having used scaffolding more at the beginning my > controllers tend to be very model centric, in that they mostly contain > all the actions for management of that particular model, which may crash > across multiple use cases. I find this effective in the sense it keeps > related actions together. However I am wondering whether it makes more > sense to split more administrative actions out into a separate > controllers? > > I imagine this could be a matter of style, experienced MVC developers > mixing the two. However any comments on the people''s experience would be > much appreciated. > > --- > > I also have a question regarding menu pages, I have many maintenance > actions that I wish to group into a section of the application. I was > thinking of having something like DashboardController with actions such > as ''maintenance'', ''warehouse'', ''accounts'' etc. These would contain views > with links to major controllers and actions specific to that area of > work. > > This seems reasonably ''tidy'', however has anyone tackled it differently? > > Thanks, Andrew. > > -- > Posted via http://www.ruby-forum.com/.
It seems that DHH is tackling this question, with his new proposal to orient everything around C/R/U/D. There''s a fundamental ambiguity here: What does a controller do? The answer right now, in Rails, is: "not much". It''s just a way of grouping a bunch of actions, for convenience. Although it''s technically called a class, it doesn''t have any of the class like things that normally make classes classes: invariants, shared private data / information hiding, encapsulation, single responsibility. Hence, it''s really never clear the "right" place to put actions, and how to group controllers. I think the Rails community would benefit from looking again at classical OO strategies. The responds_to |wants| block/switch, despiting all the raving about it, is exactly the type of thing that inheritance was designed to avoid. As Rails matures, I think we have a lot to gain by using these techniques. -- Posted via http://www.ruby-forum.com/.
We went through similar pains on our app. Eventually it became obvious with controllers linked to major areas of functionality in the system. for example, account management, team management, project management etc. Another way to go though is to just resign to the fact that controllers are weak, OO wise, in Rails right now, so simply have one controller for each page. We started out that way and refactoring ended up leading us to a better model. -------------------------------------------------- Peter Wright froogle@tinfoilcat.net Personal Blog -> http://peterwright.blogspot.com Agile Development Blog -> http://exceeding-expectations.blogspot.com On 7 Jul 2006, at 12:36, Robert James wrote:> It seems that DHH is tackling this question, with his new proposal to > orient everything around C/R/U/D. > > There''s a fundamental ambiguity here: What does a controller do? The > answer right now, in Rails, is: "not much". It''s just a way of > grouping > a bunch of actions, for convenience. Although it''s technically > called a > class, it doesn''t have any of the class like things that normally make > classes classes: invariants, shared private data / information hiding, > encapsulation, single responsibility. > > Hence, it''s really never clear the "right" place to put actions, > and how > to group controllers. > > I think the Rails community would benefit from looking again at > classical OO strategies. The responds_to |wants| block/switch, > despiting all the raving about it, is exactly the type of thing that > inheritance was designed to avoid. As Rails matures, I think we > have a > lot to gain by using these techniques. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060707/089f24ae/attachment-0001.html
Andrew Edwards
2006-Jul-08 08:33 UTC
[Rails] Re: Re: Controllers - model vs. use case centric
Thanks for the replies. I have started using smaller, model centric controllers to handle the basic CRUD for more simple models. On the more complicated models which often make use of the simpler models I favor a more use case centric approach to my controllers. I''ve also spent some time thinking ahead as to potential number of use cases and it would be madness to not split functionality into modules, everything in a flat layout would be terrible to keep track of. This again works quite well with the above scenario. Andrew. -- Posted via http://www.ruby-forum.com/.