To begin the minicourse I’m going to dive into one of the most common antipatterns in rails: overloading your controller.
Overload means to put too much weight onto. When we overload an object, or a controller, we put too much weight onto it. It’s very common to see people write resources like this:
Treating the method actions on your controller as-if they are yours to define and inventing new ones around the concept of interaction.
There are a number of basic concepts we need to get on the same page about……
• Domain context interaction : Coplein: Our mental models should be designed around both the business domain and the context in which the interaction happens.
That means that we structure our code around our mental models.
The code above is a bad mash of MVC without DCI.
The first rule of thumb with designing applications that most Rails devs seem to respect but few really understand why is this one:
Yyou must always use only these method actions in your controllers: new, create, edit, update, destroy. (You are of course allowed to use the _params method, which is private and the mechanism for strong parameters, too. Beyond that, any other methods on your controller should be themselves abstractions of functionality specific to that controller and not have routes that map to them.)
Likewise, you are always interacting with the appropriate HTTP verb (GET for new & edit; POST for create or destroy; and PUT for update).
Don’t ever do anything else.
But if you were tempted to do something else, and somehow you wrote code like what you see above, let’s see how to refactor this into a nice domain context abstraction.