# Rails Strives For DRY. A Lot of REST Routes, Not So DRY

**URL:** <https://www.ruby-forum.com/t/rails-strives-for-dry-a-lot-of-rest-routes-not-so-dry/192570>\
**Category:** Rails\
**Created:** [August 2, 2010, 11:22am UTC](https://www.ruby-forum.com/t/rails-strives-for-dry-a-lot-of-rest-routes-not-so-dry/192570 "2010-08-02T11:22:03Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![MaggotChild](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7ea924/32.png) [@MaggotChild](https://www.ruby-forum.com/u/MaggotChild)\
**Post date:** [August 2, 2010, 11:22am UTC](https://www.ruby-forum.com/t/rails-strives-for-dry-a-lot-of-rest-routes-not-so-dry/192570/1 "2010-08-02T11:22:03Z")

</div>

Most in the Rails community seem stick with 1 controller per resource  
when using RESTfull routes.  
This makes sense for a resource with one scope and one view, but once  
a resource is used with multiple scopes and/or views the amount of  
code duplication needed to manage these in a single controller can  
balloon quick. Yet despite the impending chaos, it seems as though  
people prefer to maintain a controller per resource.

Take these examples from Rails sites written by well respected  
authors:

1. [http://tinyurl.com/2d9rl3v](http://tinyurl.com/2d9rl3v)

find\_container() and find\_events(): why would one want to do this?  
This can become unmanageable. If each of these scopes require  
different view components the same checks will have to be done in the  
action’s view or when determining the layout.

1. [http://tinyurl.com/2679ye3](http://tinyurl.com/2679ye3)

Look at how many times wall? and blog? have to be called. Not very DRY  
if you ask me.  
Rail’s routing gives you these checks for free, why not create a  
WallCommentsController and BlogCommentsController? If differing views  
are involved for each of these it seems like a no brainer… but it’s  
never done. Why? What am I missing?

---

<div class="post-metadata">

**Author:** ![MaggotChild](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7ea924/32.png) [@MaggotChild](https://www.ruby-forum.com/u/MaggotChild)\
**Post date:** [August 2, 2010, 3:28pm UTC](https://www.ruby-forum.com/t/rails-strives-for-dry-a-lot-of-rest-routes-not-so-dry/192570/2 "2010-08-02T15:28:29Z")

</div>

MaggotChild wrote:

> Most in the Rails community seem stick with 1 controller per resource  
> when using RESTfull routes.

As opposed to what alternative?

> This makes sense for a resource with one scope and one view, but once  
> a resource is used with multiple scopes and/or views the amount of  
> code duplication needed to manage these in a single controller can  
> balloon quick.

Uh, not necessarily. And plugins like make\_resourceful can help too.

> Yet despite the impending chaos, it seems as though  
> people prefer to maintain a controller per resource.

That’s the way Rails MVC works. How would you avoid this, and why?

> Take these examples from Rails sites written by well respected  
> authors:
> 
> 1. [http://tinyurl.com/2d9rl3v](http://tinyurl.com/2d9rl3v)
> 
> find\_container() and find\_events(): why would one want to do this?

One wouldn’t. Those should be in a model class, or possibly a  
presenter. That much logic doesn’t belong in the controller. Perhaps  
Jamis is planning to refactor?

> This can become unmanageable. If each of these scopes require  
> different view components the same checks will have to be done in the  
> action’s view or when determining the layout.

I don’t think you’re right about these particular implications, but  
you’re right that this is poorly written.

> 1. [http://tinyurl.com/2679ye3](http://tinyurl.com/2679ye3)
> 
> Look at how many times wall? and blog? have to be called. Not very DRY  
> if you ask me.

Nor if you ask me. Some refactoring and a polymorphic association would  
really help here.

> Rail’s routing gives you these checks for free, why not create a  
> WallCommentsController and BlogCommentsController?

Because that would be even less DRY Polymorphism is probably what’s  
wanted here.

> If differing views  
> are involved for each of these it seems like a no brainer… but it’s  
> never done. Why? What am I missing?

You’re apparently missing the fact that a comment is a comment, and the  
comments controller shouldn’t need to know about the type of its parent  
object. This is why polymorphism is the right solution.

Best,  
–Â  
Marnen Laibow-Koser  
[http://www.marnen.org](http://www.marnen.org)  
removed\_email\_address@domain.invalid

Sent from my iPhone