Topic: Refactoring a large controller

I recently inherited a project that has a huge user's controller. It handles the usual RESTful user actions (new,create,edit, destroy, etc) but it also has a ton of other stuff that deals with users but almost seems out of place. It handles all of the user signup and subscription payments, which would include creating a credit card transaction.. editing and changing credit card or subscription plans and then finally initiating the transactions. There are also some image uploading functions (via attachment_fu) that deal with a user uploading images.. destroying images.. and uploading a profile image. Finally (and this is a bit messy) we have 3 different types of users -- individuals, families, and business class. They actually require very similar functionality and can almost see why they were grouped togethe.. but you have separate create methods for individual/families and businesses.

So here's the question. This Users controller is big and just seems wrong. It would seem like new controllers should be introduced.. here are some possibilities, I'm wondering what your blind suggestions would be:  Sign up controller, Photo controller, Individual/family/business controllers (they all use the same User model).

Thoughts?

Re: Refactoring a large controller

If you're following REST strictly then each controller should be limited to the 7 methods unless there is an extremely special case.

Refactor it out bud smile

http://danielfischer.com - Personal Web-Technology-Blog, Los Angeles.

Re: Refactoring a large controller

I would make signup part of the "new" and "create" actions, simply causing it to behave differently for administrators and unauthenticated users.

I would make profile images a separate resource handled by a separate controller, though it can still reference the user model.

The payment stuff, since it involves creating transactions and such, should be considered a separate resource ("transactions", perhaps, or "payment"?)

I don't know what the differences are between your classes of users, but if the functionality is largely the same, it makes sense to put them together.

Re: Refactoring a large controller

thin controller, fat model

Re: Refactoring a large controller

I would use STI for Individual/family/business and then use a separate controller for each of the types.  I find that works quite well.  While one does get more controllers and fewer databases this way it seems to make rails work easier.