Problem with RoR's controller getting too large

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?

On 4/30/07, shurain [email protected] 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.

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://blog.jayfields.com/2006/09/rails-model-view-controller-presenter.html
http://www.therailsway.com

For what it’s worth.

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.

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.

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.

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs