# Problem with RoR's controller getting too large **URL:** \ **Category:** Ruby\ **Created:** [April 30, 2007, 3:05pm UTC](https://www.ruby-forum.com/t/problem-with-rors-controller-getting-too-large/102994 "2007-04-30T15:05:39Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![shurain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3da27b/32.png) [@shurain](https://www.ruby-forum.com/u/shurain)\ **Post date:** [April 30, 2007, 3:05pm UTC](https://www.ruby-forum.com/t/problem-with-rors-controller-getting-too-large/102994/1 "2007-04-30T15:05:39Z")
Let’s assume that there are two models Post and Comment. If we have a controller dealing with both of these models, it wouldn’t take long before the controller grows too big to maintain. As far as I understand, this happens because a controller tries to handle all the actions allowed by the user. If I change the perspective and create a controller per model the controller getting too large is fixed but I have another problem. I don’t see any good way of accessing multiple controllers (or models) in one view. There are times when I have to see an instance of a Post “AND” the comments which belongs to the post. I’ve heard that it can be solved by using components but that has been deprecated and I’ve heard that there are some issues which discourage its use. Using application.rb doesn’t really help because it still makes the controller grow large. Is there any clean solution to this? ---
**Author:** ![shurain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3da27b/32.png) [@shurain](https://www.ruby-forum.com/u/shurain)\ **Post date:** [April 30, 2007, 3:45pm UTC](https://www.ruby-forum.com/t/problem-with-rors-controller-getting-too-large/102994/2 "2007-04-30T15:45:46Z")
On 4/30/07, shurain [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > “AND” the comments which belongs to the post. I’ve heard that it can > be solved by using components but that has been deprecated and I’ve > heard that there are some issues which discourage its use. Using > application.rb doesn’t really help because it still makes the > controller grow large. Is there any clean solution to this? I don’t want to sound rude, but why don’t you ask this on the RoR mailinglist? I’m sure they know more on this matter than the people that simply use Ruby for other tasks. ---
**Author:** ![shurain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3da27b/32.png) [@shurain](https://www.ruby-forum.com/u/shurain)\ **Post date:** [May 1, 2007, 3:57am UTC](https://www.ruby-forum.com/t/problem-with-rors-controller-getting-too-large/102994/3 "2007-05-01T03:57:16Z")
I share Vlad’s frustration and generally agree that Rails questions should go to the Rails list. Just for the heck of it, though, there are a couple interesting Rails-world blogs addressing this problem: [http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model](http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model) > **[Rails: Presenter Pattern](http://blog.jayfields.com/2007/03/rails-presenter-pattern.html)** > > The default architecture for Ruby on Rails, Model View Controller, can begin to break down as Controllers become bloated and logic begins to... > **[Rails Model View Controller + Presenter?](http://blog.jayfields.com/2006/09/rails-model-view-controller-presenter.html)** > > Ruby on Rails directs you to use Model View Controller by convention. This often results in a one to many relationship between Controllers ... [http://www.therailsway.com](http://www.therailsway.com) For what it’s worth. ---
**Author:** ![shurain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3da27b/32.png) [@shurain](https://www.ruby-forum.com/u/shurain)\ **Post date:** [May 1, 2007, 6:39am UTC](https://www.ruby-forum.com/t/problem-with-rors-controller-getting-too-large/102994/4 "2007-05-01T06:39:26Z")
On Apr 30, 2007, at 10:05 PM, shurain wrote: > “AND” the comments which belongs to the post. I’ve heard that it can > be solved by using components but that has been deprecated and I’ve > heard that there are some issues which discourage its use. Using > application.rb doesn’t really help because it still makes the > controller grow large. Is there any clean solution to this? For what it’s worth, this case is easily a Ruby question too. Take a Ruby angle not so much a Rails angle on this. You need to separate out some of the functionality of your controllers. Clearly they can both inherit common functions (methods) from a parent class or from a module of some kind. It really is a matter of that. It is a design issue. As for a class or set of classes (controller) growing large… this is software. Every piece of functionality added will increase complexity almost exponentially. It does become more difficult to manage it mentally. That’s what documentation and notes are for. Pen and paper become very nice tools at this point. Draw little diagrams and illustrate your design somewhat. The Ruby way is generally pretty good at keeping things smallish and manageable, and thus, self- documenting to some degree, but at some point you can’t avoid documentation and drawing. ---
**Author:** ![shurain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3da27b/32.png) [@shurain](https://www.ruby-forum.com/u/shurain)\ **Post date:** [May 1, 2007, 8:54am UTC](https://www.ruby-forum.com/t/problem-with-rors-controller-getting-too-large/102994/5 "2007-05-01T08:54:33Z")
> For what it’s worth, this case is easily a Ruby question too. Take a > Ruby angle not so much a Rails angle on this. Well, yes and no. The object-oriented design and how to apply it in Ruby part, that’s certainly a Ruby thing. But the what do I do about the specifics of Rails’ architecture and where should I put stuff if I refactor it, that’s very Rails-specific. Honestly, though, my primary metric is thread quality. We have interesting threads on R and Erlang on here sometimes. Rails is certainly more relevant than that. It’s just that there are a lot of totally underwhelming Rails questions that are kind of dispiriting. It’s kind of a quality thing. A lot of times I just want to exclude Rails questions on principle. > You need to separate out some of the functionality of your > controllers. Clearly they can both inherit common functions (methods) > from a parent class or from a module of some kind. > It really is a matter of that. It is a design issue. Yes and no, I think. Rails’ MVC dirs do kind of put you in a bind in the original poster’s use case, where you can’t map controllers to models directly. To that extent it’s on the wrong list. That’s totally just Rails stuff. The more general topic of Ruby code getting too big, though, sure. > As for a class or set of classes (controller) growing large… this > is software. Every piece of functionality added will increase > complexity almost exponentially. It does become more difficult to > manage it mentally. That’s what documentation and notes are for. Pen > and paper become very nice tools at this point. Draw little diagrams > and illustrate your design somewhat. The Ruby way is generally pretty > good at keeping things smallish and manageable, and thus, self- > documenting to some degree, but at some point you can’t avoid > documentation and drawing. Au contraire! That’s what **refactoring** is for. By the way, one fun (but potentially risky) thing about Ruby is that you can actually define one class throughout the course of very many files. I talked to a Lisp diehard who liked Ruby because he could dynamically extend different ActiveRecord models with different Ruby modules depending on how they were instantiated. It sounded kind of insane, in fact another guy at the same company told me he thought Lisp was like Kaballah, in that it carries the risk of twisting your brain permanently, but there’s a great deal of power in it. Anyway, it does actually raise some genuine questions about how you keep that twisty maze of passages all alike in some semblance of order. But that is kind of generalized out from the OP’s actual question. ---
**Author:** ![shurain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3da27b/32.png) [@shurain](https://www.ruby-forum.com/u/shurain)\ **Post date:** [May 1, 2007, 9:50am UTC](https://www.ruby-forum.com/t/problem-with-rors-controller-getting-too-large/102994/6 "2007-05-01T09:50:37Z")
On May 1, 2007, at 3:53 PM, Giles B. wrote: > is kind of generalized out from the OP’s actual question. > Indeed you can do it. But as you mentioned, refactoring is the thing > to do if things get too spread out across many files. But the devil > is in the details. These decisions are case by case. Rails’ > philosophy is convention over configuration, but that too is a > generalization. Many apps in Ruby, Rails or any other environment can > and do have special cases or different decisions. Following MVC is a > goal in many situations, but it almost never separates so cleanly, > even in Rails it is easy and necessary to put some amount of C in the > V with ERb. ---
**Author:** ![shurain](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/3da27b/32.png) [@shurain](https://www.ruby-forum.com/u/shurain)\ **Post date:** [May 2, 2007, 7:00am UTC](https://www.ruby-forum.com/t/problem-with-rors-controller-getting-too-large/102994/7 "2007-05-02T07:00:33Z")
On Mon, 30 Apr 2007 06:03:06 -0700, shurain wrote: > Let’s assume that there are two models Post and Comment. If we have a > controller dealing with both of these models, it wouldn’t take long > before the controller grows too big to maintain. As far as I > understand, this happens because a controller tries to handle all the > actions allowed by the user. If I change the perspective and create a > controller per model the controller getting too large is fixed but I > have another problem. I think you’ve created a false dichotomy. Have you, perhaps, come under the influence of the REST community? I think it’s perfectly fine to have a PostController and CommentController handle the CRUD for their respective models and also create a different controller that interacts with both models and delivers the hybrid view - that’s what controllers are for.