This document discusses concerns and presenters in Ruby on Rails. It describes concerns as reusable pieces of code that can be included in models, controllers, and other classes to DRY up code. Concerns help with modularization, separation of concerns, and refactoring code. Presenters are introduced as a design pattern that moves logic from controllers to presenter classes to clean up controllers and views and improve testability. The document provides examples and discusses pros and cons of both concerns and presenters.

1. Concerns and
Presenters
By - Aaditi Jain

2. Concerns

3. Concern : Structure

4. Concern : Dependency

5. Concern : Dependency
Methods of a concern are not invoked until the concern is included in something that is not a
concern.

6. Concerns in Models : DRYing
Example : Consider a Article model, a Event model and a Comment Model. An article or an event
has_many comments. A comment belongs_to either article or event.

7. Concerns in Models : DRYing

8. Concerns in Models : DRYing

9. Concerns in Models : Modularization
Example : Consider a Event model. A event has many attenders and comments. Typically,
the event model might look like this:

10. Concerns in Models : Modularization

11. Concerns In Controllers :
Modularization and DRYing
Concerns can be used in Controllers in a similar way as in Models.
Example:
• An Users controller, an Articles Controller, an Events Controller.
• A User has to login to view all the articles and events .
• Typically: Both Articles and Events controller will have some logic to check
that the user has logged in etc.
• Concerns : Shift all the common logic related to user in Article and Event
controller into a concern module called Authorizable. Then Include this
Authorizable module in Articles and Events Controller.

12. Concerns: Placement and Logic
Placement
• If only one concern per model/controller or One concern is being included by
multiple models/controllers: Place them directly under the concerns folder.
app/controller/concern/authorizable.rb
app/model/concern/commentable.rb
• If many concerns per model/controller: Create a folder inside the concerns
with the name of the model/controller and place them inside it.
app/model/event/attendable.rb
Logic:
Concerns should be domain based rather than technical based. For Example :
For a model, domain based concerns will be like ‘Commentable’, ‘Taggable’,
While technical based concerns will be ‘FinderMethod’, ‘ValidationMethod’

13. Concerns: Pros and Cons
Pros
• Easy to Use for refactoring.
• No external dependency
Cons
• Modules Problem
• Debugging is tougher
• No actual reduction in code. Its just better organized.

14. Presenters

15. Example :
Consider an application with this setup :

16. Problems With this Approach
• Multiple Instance Variables in Controllers :
1) Violation Of Sandi Metz Rule : One Controller action may pass only one
instance variable to its corresponding view.
2) Seperation of Concern in Controllers
• Logic creeping In the view files
Solutions : Include Logic as Models Methods
Include Logic in Helpers

17. Presenters : A Design Pattern

18. Presenters : A Design Pattern
Create a folder in your app directory with name ‘presenters’. Create a .rb file
specific to the model we are working with (user in our case)

19. Presenters : A Design Pattern

20. Presenters Pros and Cons
Pros
• Introduces Object-Oriented-ness in the View Layer
• Clean Controllers and Views
• Easy Testing.
Cons
• Generating this additional layer is a overhead.

21. Thank You :)

22. References
• https://github.com/justin808/fat-code-refactoring-techniques
• http://railscasts.com/episodes/287-presenters-from-scratch
• http://sokolmichael.com/posts/2012-01-14-model-view-
controller-presenter-better-separation-of-concern
• https://www.youtube.com/watch?v=VC5z8nadnQE