<div dir="ltr"><div class="gmail_extra">Simon, I think those are great points.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think that the reason it all feels like this is because Rails forces the application and the domain</div>
<div class="gmail_extra">objects to be instantiated by the framework, rather than the application delegating web responsibilities</div><div class="gmail_extra">to a framework.</div><div class="gmail_extra">I'm not convinced there's an Uncle Bob's Architecture The Lost Years way of having an isolated</div>
<div class="gmail_extra">application that just abstracts the web to a framework and makes Rails just a detail.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yeah you can do that to a certain extent, but for example, </div>
<div class="gmail_extra">hexagonal architecture is kind of chess-moved into a confusing-looking state of </div><div class="gmail_extra">passing the framework into a service object from the controller, then calling methods back on the framework.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">This is because Rails is not just a detail. I'm not sure it can be just a detail without serious re-working</div><div class="gmail_extra">of the way Rails works. </div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On 4 March 2014 21:21, Simon Coffey <span dir="ltr"><<a href="mailto:simon@tribesports.com" target="_blank">simon@tribesports.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 3 March 2014 20:38, Tom Blomfield <<a href="mailto:tomblomfield@gmail.com">tomblomfield@gmail.com</a>> wrote:<br>
><br>
</div><div class="">> I wrote a blog post on Interactors in Rails -<br>
> <a href="http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors" target="_blank">http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors</a><br>
<br>
</div>Nice article, thanks for sharing!<br>
<br>
To play devil's advocate, though: despite using them myself, I'm a bit<br>
unsure about service objects/interactors/use cases.<br>
<br>
We've got a fair few of them in our main app for things like user<br>
registration and so forth. While they've cleaned up our controllers<br>
somewhat, get a modest amount of reuse and are manifestly superior to<br>
AR lifecycle callbacks, I can never escape the feeling that they're<br>
still a bit of a junk drawer. ("Yeah, but what have you done for me<br>
*lately*?")<br>
<br>
Misgivings:<br>
<br>
* non-SRP: creating DB records, sending emails, firing background jobs<br>
* corollary: they tend to have a whole bunch of dependencies<br>
* corollorollary: testing them is still a pain (even with DI)<br>
* what actually *is* a UserRegistrationService instance[1]?<br>
* why do I have a whole class with a single public "run" method?<br>
<br>
It often feels like they're little more than high-ceremony functions.<br>
With Interactors there's a bit of success/failure state being<br>
maintained, but it doesn't seem to do anything that raising exceptions<br>
wouldn't (less, really, if you've got to handle multiple failure<br>
modes).<br>
<br>
We've extracted genuine cross-cutting concerns into a pub-sub event<br>
system[2], so things like email delivery are properly isolated, but<br>
there's still a gunky residue, which is why we've still got service<br>
objects.<br>
<br>
So what is that residue? In our codebase it's often things that would<br>
live in a model constructor if Rails allowed you to define<br>
constructors for your models. But the pattern isn't consistent enough<br>
that I can just say, "okay, this gunk compensates for Rails," which<br>
makes me feel like service objects are still a failure of design<br>
somehow, but I can't put my finger on what's missing.<br>
<br>
Anyone else share these doubts, or am I just making up problems for myself?<br>
<br>
Cheers,<br>
Simon<br>
<br>
[1] A ranty version of this objection:<br>
<a href="http://me.veekun.com/blog/2013/03/03/the-controller-pattern-is-awful-and-other-oo-heresy/" target="_blank">http://me.veekun.com/blog/2013/03/03/the-controller-pattern-is-awful-and-other-oo-heresy/</a><br>
[2] atrocious blogspam, sorry:<br>
<a href="http://techblog.tribesports.com/blog/2012/08/21/pub-sub-system-events-for-post-action-tasks/" target="_blank">http://techblog.tribesports.com/blog/2012/08/21/pub-sub-system-events-for-post-action-tasks/</a><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br></div></div>