# Design Advice

**URL:** <https://www.ruby-forum.com/t/design-advice/107924>\
**Category:** Rails\
**Created:** [June 27, 2007, 3:48pm UTC](https://www.ruby-forum.com/t/design-advice/107924 "2007-06-27T15:48:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\
**Post date:** [June 27, 2007, 3:48pm UTC](https://www.ruby-forum.com/t/design-advice/107924/1 "2007-06-27T15:48:07Z")

</div>

Hello all,  
I’m about to start working on a part of my application that interfaces  
with an external system using HTTP (old school, not webservices).  
Anyway, several of my controllers will need to access this  
functionality, but there are some places where the functionality doesn’t  
fit perfectly with my design. I was thinking about putting most of the  
interaction with the external site in its own controller and then  
calling that from controllers in my application as needed. Of course,  
such a controller wouldn’t be associated with a model. I’m not sure what  
effect this will have.

How would you handle it?

* * *

Ready for the edge of your seat? Check out tonight’s top picks on Yahoo!  
TV.

---

<div class="post-metadata">

**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\
**Post date:** [June 27, 2007, 4:10pm UTC](https://www.ruby-forum.com/t/design-advice/107924/2 "2007-06-27T16:10:09Z")

</div>

I’d put it into a class under lib/ and not into a controller;  
controllers shall be thin and glue the view and the model. it depends  
how you “see” your external resource; you can look at it like a model.

a bit more important could be the fact that external access to the  
resource will lock-up your users request and bind one of your mongrel  
(or rails instances) to that request. you can use backgroundrb (http://  
[backgroundrb.rubyforge.org/](http://backgroundrb.rubyforge.org/)) for such cases and communicate  
asynchronously with your external system.

---

<div class="post-metadata">

**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\
**Post date:** [June 27, 2007, 4:12pm UTC](https://www.ruby-forum.com/t/design-advice/107924/3 "2007-06-27T16:12:21Z")

</div>

There’s nothing wrong with controllers that aren’t directly related to a  
model. If there are methods multiple controllers will use then I would  
think the best place to put them is in the application controller.  
Anyway, it’s a good idea to plan ahead, I think you’re on the right  
track.

---

<div class="post-metadata">

**Author:** ![hotgazpacho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/a587f6/32.png) [@hotgazpacho](https://www.ruby-forum.com/u/hotgazpacho)\
**Post date:** [June 27, 2007, 4:13pm UTC](https://www.ruby-forum.com/t/design-advice/107924/4 "2007-06-27T16:13:09Z")

</div>

Hi Will,

I would hide the external system behind a Model. I view Controllers as  
those things that manage the interactions between the ‘things’ in an  
application. An external system, as it appears, is another ‘thing’ in  
your  
application.

This gives you the ability to use this Model in other controllers, or  
other  
applications should the need arise.

However, I’m sure you’ll get plenty of options from this list on which  
to  
choose a solution that fits your needs.

Cheers,  
Mel R.