[LRUG] Rails - The Missing Parts

[Mark Burns]

Simon, I think those are great points.

I think that the reason it all feels like this is because Rails forces the
application and the domain
objects to be instantiated by the framework, rather than the application
delegating web responsibilities
to a framework.
I'm not convinced there's an Uncle Bob's Architecture The Lost Years way of
having an isolated
application that just abstracts the web to a framework and makes Rails just
a detail.

Yeah you can do that to a certain extent, but for example,
hexagonal architecture is kind of chess-moved into a confusing-looking
state of
passing the framework into a service object from the controller, then
calling methods back on the framework.

This is because Rails is not just a detail. I'm not sure it can be just a
detail without serious re-working
of the way Rails works.


On 4 March 2014 21:21, Simon Coffey <simon at tribesports.com> wrote:

> On 3 March 2014 20:38, Tom Blomfield <tomblomfield at gmail.com> wrote:
> >
> > I wrote a blog post on Interactors in Rails -
> >
> http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors
>
> Nice article, thanks for sharing!
>
> To play devil's advocate, though: despite using them myself, I'm a bit
> unsure about service objects/interactors/use cases.
>
> We've got a fair few of them in our main app for things like user
> registration and so forth. While they've cleaned up our controllers
> somewhat, get a modest amount of reuse and are manifestly superior to
> AR lifecycle callbacks, I can never escape the feeling that they're
> still a bit of a junk drawer. ("Yeah, but what have you done for me
> *lately*?")
>
> Misgivings:
>
> * non-SRP: creating DB records, sending emails, firing background jobs
> * corollary: they tend to have a whole bunch of dependencies
> * corollorollary: testing them is still a pain (even with DI)
> * what actually *is* a UserRegistrationService instance[1]?
> * why do I have a whole class with a single public "run" method?
>
> It often feels like they're little more than high-ceremony functions.
> With Interactors there's a bit of success/failure state being
> maintained, but it doesn't seem to do anything that raising exceptions
> wouldn't (less, really, if you've got to handle multiple failure
> modes).
>
> We've extracted genuine cross-cutting concerns into a pub-sub event
> system[2], so things like email delivery are properly isolated, but
> there's still a gunky residue, which is why we've still got service
> objects.
>
> So what is that residue? In our codebase it's often things that would
> live in a model constructor if Rails allowed you to define
> constructors for your models. But the pattern isn't consistent enough
> that I can just say, "okay, this gunk compensates for Rails," which
> makes me feel like service objects are still a failure of design
> somehow, but I can't put my finger on what's missing.
>
> Anyone else share these doubts, or am I just making up problems for myself?
>
> Cheers,
> Simon
>
> [1] A ranty version of this objection:
>
> http://me.veekun.com/blog/2013/03/03/the-controller-pattern-is-awful-and-other-oo-heresy/
> [2] atrocious blogspam, sorry:
>
> http://techblog.tribesports.com/blog/2012/08/21/pub-sub-system-events-for-post-action-tasks/
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140304/c7d86955/attachment.html>