In the last part of the Intro course, Matt added a few methods like signed_in?, current_user and so forth to the ApplicationController so they would be available to all controllers, and in some cases, also the views using helper_methods.
Does this scale for more complicated applications? It seems like ApplicationController would become a dumping ground for common methods that may apply to many but not necessarily all Controllers. In my current language, I like keeping controllers narrowly focused so they don’t cross concerns if they can avoid it. Creates yet another place to look for code too when you need to update.
I’m new to rails but have a lot of development experience so trying to understand how this plays out in “real” applications. Thanks!
putting business logic in helpers is the “Rails way”. I used to do that too at the beginning, but I suddenly felt the pain of doing that as soon as I started TDD.
Testing a helper method that lives in a controller is not easy. What I like to do is to extract the logic of a helper into a service, so that I can test it in isolation. I always try to put a layer of abstraction between my app and Rails.
You’ll have a cleaner design that is far easier to maintain and to understand.
Here is a post that helped me a lot. Is a post by Steve Klabnik about Plain Old Ruby Objects in Rails.
Thanks @gmodarelli - Klabnik’s article is more in line with my previous experience. Do “good” rails apps then tend not to have helpers or are the helpers simply delegating to models (maybe PORO, maybe Rails)? Helpers seem like an easy but unclean way to expose utility methods to an application, especially a view?