[LRUG] Encapsulation/Responsibility delegation and API versioning.

[Tom Ward]

I wrote a post about how we used presenters in building the API for
hashblue.com: http://tomafro.net/2011/08/presenting-the-hashblue-api

I've been very happy with the way it's turned out.

Tom

On 22 August 2011 18:24, Ian Leitch <port001 at gmail.com> wrote:
> Well pointed out, I think I actually prefer this approach to using
> some kind of proxy/decorator for the models for a few reasons:
>
> 1) Version specific logic is encapsulated into discrete classes,
> rather than a module only overriding portions of an existing class.
> 2) I wont suffer the pains of multiple inheritance.
> 3) Less magic, I don't need an external library or some boilerplate to
> facilitate the functionality.
> 4) Possibly a little less fussy to test.
> 5) I can employ the exact same paradigm as I would with a presenter
> for an HTML view (as you pointed out).
>
> My controllers will mostly boil down to something like this:
>
> render :json => Api::Presenter::V1::ScanPresenter.new(scan)
>
> I'm going to give this approach a whirl for now.
>
> Cheers
>
> On 22 August 2011 17:18, Graham Ashton <graham at effectif.com> wrote:
>> On 22 Aug 2011, at 16:16, Ian Leitch wrote:
>>
>>> The smell that's now beginning to emerge is that controllers are
>>> getting fat with protected helper methods that build data structures
>>> for conversion into JSON.
>>
>> Converting data to JSON sounds like presentation layer to me; you could think of it an as an alternative view.
>>
>>> What solutions have other people used for this problem?
>>
>> It reminds me a lot of how the presenter pattern often gets used in Rails, with presenter classes getting stored in app/presenters.
>>
>>> I'm almost considering a layer in between my controllers and models,
>>> almost like a presentation layer from model to controller.
>>
>> From what you've described, it sounds to me as though the layer you're missing wouldn't sit between those two, but would replace the view.
>>
>>> Mixins could help here... perhaps something like this?
>>
>> Rather than mix some rendering API into a model, I'd make rendering objects and initialise them by passing a model in. Let them get any data they need from the model and encapsulate the logic about how to create JSON in the renderer.
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>