Hi Thanks for a great list! The following is my thoughts about combating controller bloat. I have been working with Rails since December 2004 and have read the Rails book. I''m not a newcomer to either Rails nor object oriented analysis and design, and I have quite a few years of programming experience (java, python, php). The book states: "The Rails controller is the logical center of your application. It coordinates the interaction between the user, the views, and the model.". That''s what controllers should do. Alas my Rails controllers seem to suffer a bit from bloating. When an application is initially scaffolded, all CRUD operations on ActiveRecord objects are present in a single controllers. When you want to add functionality, it''s tempting to just add a new action in a controller where it seems most approriate. 2 days, 10 actions and a similar number of .rhtml files later this scheme will definetely show its limits, and a need for more, less complex, controllers arise. In my experience working with AJAX makes it more difficult to see when a new controller should be written, because you are only working on a subportion of the viewport. To be consistent throughout the app, I needed to work out a set of guidelines for when a new controller is appropriate to have a clear picture of what should go in the specific controllers and what should not. I would like to work with a methodology where user interactions with atomar goals, f.ex. opening an account, are assembled in single controllers. Such goals can be consistently derived from analysis, UML documents, use cases or whichever method you use for designing the users interaction with you app. However persuing this methodology puts you at risk of dividing CRUD operations into more controllers. Update operations might be needed from both the create-user controller and the manage-user controller. My suggestion is to assemble core CRUD operations in central controller, and simply subclass new controllers from that. Then I would have a controller managing core update operations on the user objects, and at the same time more specialized behaviour on the same objects would be neatly tucked away in dedicated controllers, without loosing the core functionality. Regards Kasper Weibel