Ruby on Rails patterns - decorator vs presenter

ruby-on-rails design-patterns decorator presenter

36,188

Solution 1

A decorator is more of a "let's add some functionality to this entity". A presenter is more of a "let's build a bridge between the model/backend and view". The presenter pattern has several interpretations.

Decorators are generic/general purpose. Presenters have a narrower range of responsibilities/uses. Decorators are used across domains, presenters are almost always related to view-like functionality.

Draper site
RailsCasts Draper Episode

Solution 2

I suggest you to check this - Exhibit vs Presenter.

Decorator is a design pattern that is used to extend the functionality of a specific object by wrapping it, without effecting other instances of that object. In general, the decorator pattern is an example of the open/close principle (the class is closed for modifications, but available for extensions).

Both the exhibit and presenter patterns are a kind of the decorator pattern.

36,188

Author by

keruilin

Updated on July 08, 2022

Comments

keruilin almost 2 years

There is all sorts of talk lately in the Ruby on Rails community about decorators and presenters.

What is the essential difference between the two? If there is, what are the clues that tell me which one to use over the other? Or perhaps to use the two in conjunction?
keruilin over 12 years

Thanks. Seems like that Draper gem is a hybrid of presenter and decorator.
smudge over 12 years

@keruilin One thing to keep in mind: Decorators should really be able to decorate other decorators (as well as decorating the component object), because one of their purposes is to get around the limitations of inheritance. (Draper does not do this). The decorator pattern is very similar to the composite pattern in that sense, except handled from outside-in instead of inside-out (if that makes sense).
Kris almost 12 years

I see a decorator as a general purpose pattern, and presenter as a specific application of decorator related to the view layer.
keruilin almost 12 years

@Smudge, draper decorators can decorate other decorates, at least as if the underlying models have an STI relationship.
ki4jnq over 8 years

+1 for linking to that blog post by Mike Pack. Excellent post that explains the differences between the patterns.
Yonk over 7 years

+1 for mentioning the Exhibit pattern. I ended up getting Avdi Grimm's book that explains it. Although, it wasn't the right solution for my problem it's still an amazing pattern. Excellent food for thought.
Jared almost 5 years

It seems that now Draper identifies itself as presentation layer wrapper - so it's no longer a decorator, but a presenter actually. From their GH: "Draper adds an object-oriented layer of presentation logic to your Rails application."
Dave Newton almost 5 years

@Jared shrug While I didn't present Draper as either in particular, that verbiage has been in the readme as long as I can remember. Presenters are decorators that live close to the presentation layer--it's still a decorator. How a decorator is used, as I roughly stated in the answer, is an implementation detail. It doesn't really change either pattern--and Draper can be used as either.
Jared almost 5 years

@DaveNewton my fault, browsing their README history, says they've been always this way. It must that long time ago it was introduced to me as logic level decorator and presenters could use them.
Dave Newton almost 5 years

@Jared shrug You can--it's just a decorator; doesn't matter what you're decorating. I've used Draper as both. There's nothing view-y about it, really.
Jared almost 5 years

@DaveNewton yeah, I've been using Draper for many years, always as logic decorator. It is just surprising to me that they almost insist to use it only for views as it helps avoids many errors due to misconceptions. Never really got into errors with it, although I've been through some quirks with Draper.
Dave Newton almost 5 years

@Jared I guess I don't read it the same way. IMO it's (ahem) presented this way because that's the way most people will use it if only because the "edges" of an object's use, at least in action-oriented frameworks, are almost always some form of view, whether it's in HTML, JSON, SOAP, whatever--and this is where you'll often need "edge"-specific functionality. If it's passing through multiple layers of an application a decorator seems less useful, but YMMV.