The default architecture for Ruby on Rails, Model View Controller, can begin to break down as Controllers become bloated and logic begins to creep into view templates.

The Presenter pattern addresses these problems in concert by creating a class representation of the state of the view. An architecture that uses the Presenter pattern provides view-specific data as attributes of an instance of the Presenter. The Presenter's state is an aggregation of model and user-entered data.

As non-trivial applications grow Controllers can approach sizes that compromise maintainability. Complex controller actions may require instantiation of multiple objects and take on the responsibility of aggregating data from various objects. A Presenter can encapsulate this aggregation behavior and leave the controller with more focused responsibilities. This also allows for testing of aggregation or calculation behavior without a dependency on setting up a Controller to a testable state.

Since views are templates they can also contain behavior. Generally, the most common behavior you encounter is formatting. However, since the view is a template you will occasionally see computations or worse. Because this logic is stored in a template it can be problematic to test. Presenters address this problem by pulling all formatting, computation, and any additional behavior into a class that can be easily tested.

Used appropriately, Presenters greatly benefit an application's architecture and maintainability.