从服务对象到交互者

如果您在任何大型Rails应用程序上工作,则可能会遇到服务对象模式,这是用于处理业务逻辑的有用抽象。 最近,我们一直在使用Interactor gem对该模式进行特定的实现。 要了解交互器的好处,先讨论一下服务对象以及它们在Rails中的用法是很有帮助的。 在Rails的上下文中,服务对象只是用于特定业务操作的Ruby对象。 该代码通常不属于控制器或模型层,因为它可能涉及多个数据模型,或者它命中了第三方API。 在用户响应调查的情况下,这是服务对象的一个​​虚构示例,在该上下文中,用户通过响应获得某种奖励积分: 您可以像这样在控制器中使用它: 在Reflektive,我们广泛使用服务对象来封装操作,例如更换员工经理,启动审查周期或处理Slack的实时反馈。 随着我们的团队和代码库的增长,我们遇到的一个问题是缺乏关于如何编写服务对象的既定惯例,因此不同团队的工程师将以不同的方式来编写它们。 一些拥有许多公共方法,而其他只有一种。 有些处理错误,而其他则没有。 有些人担心数据的完整性,以防ActiveRecord事务中任何与数据相关的操作失败。 作为一个团队,我们讨论了我们希望从服务对象中获得什么:一致性,数据完整性,单一责任和错误处理。 这使我们找到了Interactor的宝石,它是由Collective Idea的好人创造的。 这个gem提供了一个很棒的API,可以满足我们在服务对象等方面的更多需求。 我鼓励您阅读文档,因为该库非常简单且编写得很好。…