[LRUG] Encapsulation/Responsibility delegation and API versioning.

[Ian Leitch]

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
>