Schienen Service Objekte und Controller

Question

Ich habe einen Kollegen, der gerne die Steuerung in ein Service-Objekt übergeben. Zum Beispiel könnte eine Controller-Methode die folgende Art und Weise aussehen:

class FooController < ApplicationController 

    ... 

    def show 
    Foo.new(self).call 
    end 

    ... 

end 

das Service-Objekt wie folgt aussieht dann:

class Foo 

    attr_reader :controller, :resource_id 

    delegate :render, :params, :head, to: :controller 

    def initialize(controller, resource_id) 
    @controller = controller 
    @resource_id = resource_id 
    end 

    def call 
    resource = SomeActiveRecordModel.find(resource_id) 
    if resource 
     render json: resource.to_json 
    else 
     head :not_found 
    end 
    end 

end 

Irgendwie habe ich das Gefühl, dass dies kontraproduktiv und eine Instanz von cargo-Kult Software Engineering.

Ich würde es vorziehen, das Service-Objekt vollständig getrennt von der Steuerung zu halten. Abhängigkeiten würden in den Konstruktor des Dienstobjekts übergeben, Parameter würden als Methodenargumente an das Dienstobjekt übergeben. Jedes Ergebnis wird einfach von der Methode zurückgegeben.

Leider sind meine Kollegen nicht gerade begeistert, wenn ich es in einem Code-Review aufbringe, was ich wiederum relativ frustrierend finde.

Was sind die Vor- und Nachteile der jeweiligen Ansätze? Wie kann ich meinen Fall besser argumentieren? Fehle ich hier etwas?

Answer 1

Ich vermute, die Antwort ist "es kommt darauf an".

In dem genauen Beispiel, das Sie gaben, sehe ich keinen besonderen Vorteil und es schafft einen Grad der Verschleierung. Außerdem stimme ich Ihnen im Allgemeinen zu, das Serviceobjekt vom Controller getrennt zu halten.

Es gibt jedoch Zeiten, in denen ich finde, dass ich den Controller in das Serviceobjekt überlasse. Zum Beispiel, wenn ich viel komplexe Arbeit habe, um dynamisch eine Ansicht zu konstruieren.