Controller Design Patterns

Rails has a concept of a controller. Simplistically, a controller is something which responds to web requests. I've seen several different controller patterns emerge in my applications. These are:

• Resource (or asset) service.  I use this pattern when I need to return an image or other monolithic object without exposing a directory path in the URL.
• JSON-based restful API's.
• HTML document services.

The JSON patterns are used to provide access to the business and/or domain logic.  These tend to be fairly pure and understandable.

The HTML document services are a hybrid of presentation, business, and domain logic.  They can be messy as the presentation is coupled to the business part.

For both JSON and HTML patterns, there are variants:

• ActiveRecord model wrappers.  The ActiveRecord model pattern supplies well-checked (robust) CRUD operations.  Constructor parameters use the params associative hash and thus need to handle checking and deserialization.  The controller code delegates all of its work to the underlying model.
• ActiveModel model wrappers.  These are akin to ActiveRecord, only not persisted to the database.
• Other

Rails is really good at generating controllers that are HTML ActiveRecord model wrappers.

The HTML controller has another variant which is composite presentation.  Parts of the composite happen naturally in Rails using application templates.  Other times the controller is merging the presentation of multiple other controllers.  This happens on things like user account summary pages.

Subsequent blogs will talk about controller design problems and solutions.