Introducing Interactors to represent getting stuff done.
This post introduces interactors, also know as usecases or service objects. See how your domain code can be separated from your framework. http://insights.workshop14.io/2015/08/16/introducing-interactors-to-represent-getting-stuff-done.html
Comments
So annoying : I posted 10mn ago an article about precisely the same theme - huh the 1st part of it actually…
Well the more the merrier. I am using a gem for my Interactions, it’s still in a very early stage but it made its way in all my projects, you might be interested : https://github.com/charly/paramount
Is that gem just about form objects? or form objects and an interactor. I don’t know if you have seen the form object gem I have used with my interactors, https://github.com/CrowdHailer/vulcanize, Be interested to discuss more, there might be some common ground and we can combine efforts
Interesting. You’re actually ahead of me because I don’t separate (yet?) the notion of form object and interactor. Paramount (with virtus and activemodel) is both and intends to extract all the user<->model interactions from activeRecord : validations, association, nested_attributes, strong params, callbacks, context (no more ifs…) So I might still be mixin responsibilities but I’m taking one step at the time while parting from the rails way. 2 reasons : familiarity and keeping the level of indirections low. I’ll be looking at vulcanize closely, could very well be an alternative to virtus…
I have separated pretty much everything I possible could. If your saw the first post I admitted to over design. I think that probably the sensible route forwards is a slight consolidation of what I am trying. For example I have tried implementing interfaces in ruby to guard the form objects. Its an interesting gist but not used it yet
Post a comment