Forum: Ruby on Rails architecture question: reusing code across controllers?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jacob (Guest)
on 2007-05-11 21:54
(Received via mailing list)
Hi all,

I'm building my first Rails app and looking for some advice about how
to architect my controllers. I'm essentially building a sales tracker.
Sellers log in and post their sales; buyers log in and see a list of
their purchases. Admins can do everything sellers and buyers can do.

So far I've built out the admin controller. It now has most of the
app's functionality, and in the process I've gotten comfortable with
Rails. Now, I'm ready to build the more specific app functionality
which will allow sellers and buyers to log in and interact with the
data from their different perspectives. Here's where I hit an
architecture question and would love some advice.

My question: Should i create separate controllers for both buyers and
sellers? Initially I thought yes, since the options available to these
two sets of users will be different. But now I'm realizing that they
will also share quite a bit of code with each other and with the admin
controller. For example, "view sale details" is the same whether it's
in a buyer context, a seller context, or an admin context.

How best should I architect my app to keep DRY? Should I make the
buyer and seller controllers children of the admin controller, thus
inheriting its methods? Somehow this doesn't seem quite right. Is
there some other way to reuse code across multiple controllers? Or
maybe these shouldn't be separate controllers after all?

Thanks in advance and please let me know if you need more specific
info to be able to offer advice.

Cheers,
Jacob
Kim S. (Guest)
on 2007-05-11 23:45
(Received via mailing list)
On May 11, 2007, at 11:52 AM, Jacob wrote:

> Rails. Now, I'm ready to build the more specific app functionality
> which will allow sellers and buyers to log in and interact with the
> data from their different perspectives. Here's where I hit an
> architecture question and would love some advice.
>

So far, so good.

> My question: Should i create separate controllers for both buyers and
> sellers? Initially I thought yes, since the options available to these
> two sets of users will be different. But now I'm realizing that they
> will also share quite a bit of code with each other and with the admin
> controller. For example, "view sale details" is the same whether it's
> in a buyer context, a seller context, or an admin context.
>
> How best should I architect my app to keep DRY?

I hesitate to give a hard and fast rule, but based on your description,
I would look at moving the methods from your admin controller that will
be used for the buyer and seller, into the application controller.
Because
all controllers inherit from the application controller, you can put
shared functionality there.  If you are going to have other controllers
that do not need this functionality, I would look at making a subclass
of the application controller that contains the shared functionality and
then having the admin, buyer, and seller controllers inherit from that.

> Should I make the
> buyer and seller controllers children of the admin controller, thus
> inheriting its methods? Somehow this doesn't seem quite right.

That does not sound good to me, either.

> Is
> there some other way to reuse code across multiple controllers?

See my comments above.

> Or
> maybe these shouldn't be separate controllers after all?
>

That's really a judgement call that only you can make.  Based on your
description, I would tend to make them separate controllers.

> Thanks in advance and please let me know if you need more specific
> info to be able to offer advice.
>
> Cheers,
> Jacob

Kim
--
  Kim S. - principal, Shrier and Deihl - 
mailto:removed_email_address@domain.invalid
Remote Unix Network Admin, Security, Internet Software Development
   Tinker Internet Services - Superior FreeBSD-based Web Hosting
                      http://www.tinker.com/
This topic is locked and can not be replied to.