Encapsulation/Responsibility delegation and API versioning.
Ian Leitch
many people registered to both. Apologies if you are; there are many
intelligent people on this list whose thoughts I didn't want to miss
out on).
Hey list,
I'm working on a Rails API that's the backend for an iPhone app. Given
that I'll have no control over when a user may choose to up upgrade
to the latest version of the app, I'm taking steps to ensure that each
of my API versions are very much self-contained. When I need to bump
the version, i'll simply duplicate the controllers.
I've worked on apps before where you'd have multiple controller
versions calling down to a shared model method - this is a time bomb I
want to avoid.
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. Normally I'd push these down into the
model/some class, but like I said, I need API versions to remain
self-contained.
My initial thought was to suffix model methods with the API version,
i.e attributes_for_json_api_v1 but that'll soon result in fat models,
which I dont want.
What solutions have other people used for this problem?
I'm almost considering a layer in between my controllers and models,
almost like a presentation layer from model to controller. Mixins
could help here... perhaps something like this?
https://gist.github.com/1162618
Could get messy if the controller uses a large number of models?
Thoughts welcome!
Cheers
Ian
Steve Hoeksema
> almost like a presentation layer from model to controller. Mixins
> could help here... perhaps something like this?
> https://gist.github.com/1162618
> Could get messy if the controller uses a large number of models?
> Thoughts welcome!
I posted on this list with the same problem late last year, and ended up doing just this.
I tried using built-in views but it seemed like more trouble than it was worth, particularly to render either a JSON object or an array of JSON objects without hacks or duplicating code.
It ended up something like this: https://gist.github.com/1163453
Each service I needed to present an object to got its own class, and implemented as_json, as_xml, as_kml, etc.
Ian Leitch
Presenters. Should have been obvious to me this was a view layer
problem instead of a model one!
> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
>
>
Ian Leitch
controller, i.e Api::V1::FooPresenter.
Nathan de Vries
Mike Williams
>> I'm almost considering a layer in between my controllers and models,
>> almost like a presentation layer from model to controller. Mixins
>> could help here... perhaps something like this?
>> https://gist.github.com/1162618
>> Could get messy if the controller uses a large number of models?
>> Thoughts welcome!
>
> I tried using built-in views but it seemed like more trouble than it was worth, particularly to render either a JSON object or an array of JSON objects without hacks or duplicating code.
IMHO, a JSON (or XML) representation of your data is no less a "view" than an HTML representation. I think you guys (Ian and Steve) are taking the right approach by de-coupling the JSON generation from both controller AND model.
Nathan's already mentioned my "Representative" gem, which was built to address exactly this problem, with a FormBuilder-like DSL for extracting properties from objects. It's not necessarily any better than what you suggest, just slightly more succinct.
See also: "If you’re using to_json, you’re doing it wrong."
http://engineering.gomiso.com/2011/05/16/if-youre-using-to_json-youre-doing-it-wrong/
--
cheers,
Mike Williams