Ein Fall gegen Formobjekte

Hinweis:Während diese Diskussion Ruby on Rails-Beispiele verwendet, gelten die Kernkonzepte allgemein für andere Sprachen und Frameworks.

Das Problem mit Formularobjekten: Eine kritische Betrachtung

Lassen Sie uns das oft mehrdeutige Konzept von „Formularobjekten“ in der Webanwendungsentwicklung klären. Basierend auf verschiedenen Artikeln (unten verlinkt) und praktischen Erfahrungen fehlt für Formularobjekte eine allgemein anerkannte Definition und ein allgemein anerkannter Zweck. Ihre Rollen werden häufig wie folgt beschrieben:

• Datenvalidierung: Einfache Ruby-Objekte, die Benutzereingaben validieren.
• Modellaggregation:Virtuelle Modelle, die Daten aus mehreren Modellen darstellen.
• Ersetzung starker Parameter:Eine Alternative zu starken Parametern zur Eingabebereinigung.
• Callback-Refactoring: Ein Mittel zur Reorganisation von Modelllebenszyklus-Callbacks.
• form_forHelfer:Objekte, die speziell für die Verwendung mit dem form_forHelfer von Rails entwickelt wurden.

Als Hauptziel wird oft die Vereinfachung von Controllern durch die Handhabung der Parameterverarbeitung, der Typerzwingung und der grundlegenden Validierung genannt. Sie werden auch verwendet, um Aktualisierungen an mehreren ActiveRecord-Modellen aus einer einzigen Formularübermittlung zu kapseln und so das Verhalten von ActiveRecord nachzuahmen, um mit dem Controller vertraut zu sein. Sie werden als Möglichkeit zur Bewältigung komplexer Verhaltensweisen dargestellt.

Warum Formularobjekte verwenden? Die beabsichtigten Vorteile:

Zu den angeblichen Vorteilen gehören:

• Entkopplung:Trennung der Geschäftslogik von Controllern und Modellen.
• Helfer anzeigen: Bereitstellung von Hilfsmethoden für komplexe Formularelemente (z. B. Optionen für ausgewählte Felder).
• Einhaltung der Rails-Konvention: Vereinfachung komplexer Formulare, die nicht direkt auf einzelne ActiveRecord-Modelle abgebildet werden können.

Das Fehlen einer klaren Definition führt jedoch zum ersten großen Problem: schlechte Kommunikation. Wenn in einer Codebasis auf Formularobjekte gestoßen wird, ist unklar, welche dieser Rollen (oder eine Kombination davon) sie erfüllen.

Im Wesentlichen zielen Formularobjekte darauf ab, die Komplexität des Codes durch Zentralisierung von Verantwortlichkeiten, typischerweise innerhalb der Modell- und/oder Controller-Ebenen, umzugestalten. Dies führt jedoch zum zweiten Problem: unbeabsichtigtes Aufblähen.

Der Nachteil: Das „Fat Form Object“-Anti-Pattern

Erwägen Sie eine gemeinsame Implementierung:

class SomethingController
  def create
    @form = MyForm.new(action_params)
    if @form.valid?
      @form.save!
      redirect_to "somewhere"
    else
      render :new
    end
  end
  def new
    @form = MyForm.new
  end
end

Dieser scheinbar unkomplizierte Ansatz verbirgt ein erhebliches Problem. Die öffentliche API des Formularobjekts (new, valid?, save! und seine Präsenz in der Ansicht) zeigt, dass es Folgendes verarbeitet:

• Parameter-Parsing: Anforderungsparameter verstehen und transformieren.
• Validierung:Kenntnis von Parametertypen und Validierungsregeln (Geschäftslogik).
• Persistenz: Wissen, wie man Daten erstellt und beibehält (Interaktion mit der Datenbank).
• Ansichtslogik: Enthält möglicherweise ansichtsbezogene Logik (Hilfsmethoden für Formularelemente).

Dies verstößt gegen das Prinzip der Einzelverantwortung. Das Formularobjekt wird zu einem Repository für verschiedene Anliegen und zieht mit der Zeit mehr Verantwortlichkeiten nach sich (zusätzliche Ansichtshelfer, Validierungsregeln usw.). Es entwickelt sich zu einem „fetten Objekt“, das genau die Probleme widerspiegelt, die es lösen sollte.

Das dritte Problem: Redundanz

Eine größere Sorge besteht darin, dass diese Verantwortlichkeiten oft bereits von anderen Komponenten übernommen werden:

• Beharrlichkeit: Dies liegt in der Verantwortung des Models. Delegieren Sie an das Modell, anstatt seine Funktionalität zu replizieren.
• Geschäftslogik:Verwenden Sie Serviceobjekte für komplexe Geschäftslogik.
• Eingabevalidierung:Verwenden Sie Validierungsbibliotheken (ActiveRecord::Model, Scrivener, dry-schema).
• Helfer anzeigen:Verwenden Sie Ansichtsmodelle oder Moderatoren.

In mittleren bis großen Anwendungen sind diese Komponenten wahrscheinlich bereits vorhanden. Die Einführung von Formularobjekten mit überlappenden Verantwortlichkeiten führt zu unnötiger Komplexität und architektonischer Mehrdeutigkeit. Komplexität sollte direkt angesprochen und nicht verschleiert werden.

Eine vorgeschlagene Alternative: Ein modularerer Ansatz

Ein strukturierterer Ansatz verwendet dedizierte Objekte für jede Verantwortung:

class SomethingController
  def create
    @form = MyForm.new(action_params)
    if @form.valid?
      @form.save!
      redirect_to "somewhere"
    else
      render :new
    end
  end
  def new
    @form = MyForm.new
  end
end

Vorteile dieses Ansatzes:

• Klare Verantwortlichkeiten:Jedes Objekt hat einen einzigen, klar definierten Zweck.
• Testbarkeit:Einfachere und schnellere Prüfung einzelner Komponenten.
• Wartbarkeit:Verbesserte Codestruktur und Wartbarkeit.

Fazit:

Formularobjekte sind nicht grundsätzlich schlecht. Sie können von Nutzen sein, wenn sie mit Bedacht eingesetzt werden. Ihre vage Definition und ihre Tendenz zur Aufblähung der Verantwortung erfordern jedoch eine sorgfältige Prüfung. Bevor Sie ein Formularobjekt einführen oder verwenden, überlegen Sie, ob bereits vorhandene Komponenten die erforderliche Funktionalität beherrschen. Wenn Komplexität vorhanden ist, erfassen Sie sie durch klar definierte Einzweckobjekte, anstatt sie in einem schlecht definierten „Formobjekt“ zu verbergen.

Verlinkte Artikel (aus Gründen der Übersichtlichkeit neu formatiert):

• 7 Muster zur Umgestaltung fetter ActiveRecord-Modelle
• Disciplined Rails: Techniken und Muster für Formobjekte – Teil 1
• Grundlegende RubyOnRails-Muster – Teil 4: Objekte bilden
• ActiveModel-Formularobjekte
• So halten Sie Ihre Controller mit Formobjekten dünn
• Formularobjekte in Ruby on Rails verwenden
• Formularobjekte validieren
• Formularobjekte mit ActiveModel erstellen
• Refaktorieren Sie Ihren Code mit Form Objects

Das obige ist der detaillierte Inhalt vonEin Fall gegen Formobjekte. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!