Concerns and Presenters

By - Aaditi Jain

Concerns

Concern : Structure

Concern : Dependency

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

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.

Concerns in Models : DRYing

Concerns in Models : DRYing

Concerns in Models : DRYing

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

Concerns in Models :

Modularization

Concerns in Models :

Modularization

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.

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’

Concerns: Placement and

Logic

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.

Presenters

Example :Consider an application with this setup :

• 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

Problems With this Approach

• Logic creeping In the view files Solutions : Include Logic as Models Methods Include Logic in Helpers

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)

Presenters : A Design Pattern

Presenters : A Design Pattern

Pros• Introduces Object-Oriented-ness in the View Layer • Clean Controllers and Views• Easy Testing.

Cons• Generating this additional layer is a overhead.

Presenters Pros and Cons

Thank You :)

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