Un cas contre les objets de formulaire

Remarque : Bien que cette discussion utilise des exemples Ruby on Rails, les concepts de base s'appliquent largement à d'autres langages et frameworks.

Le problème des objets de formulaire : un examen critique

Clarifions le concept souvent ambigu d'« objets de formulaire » dans le développement d'applications Web. Sur la base de divers articles (liens ci-dessous) et d'expériences pratiques, les objets de forme n'ont pas de définition et d'objectif universellement acceptés. Leurs rôles sont fréquemment décrits comme :

• Validation des données : Objets Ruby simples validant les entrées de l'utilisateur.
• Agrégation de modèles : Modèles virtuels représentant les données de plusieurs modèles.
• Remplacement de paramètres forts : Une alternative aux paramètres forts pour la désinfection des entrées.
• Refactoring des rappels : Un moyen de réorganiser les rappels du cycle de vie des modèles.
• form_for Helpers : Objets spécialement conçus pour être utilisés avec l'form_for helper de Rails.

L'objectif principal est souvent cité comme simplifiant les contrôleurs en gérant le traitement des paramètres, la coercition de type et la validation de base. Ils sont également utilisés pour encapsuler les mises à jour de plusieurs modèles ActiveRecord à partir d'une seule soumission de formulaire, imitant le comportement d'ActiveRecord pour la familiarité du contrôleur. Ils sont présentés comme un moyen de gérer des comportements complexes.

Pourquoi utiliser des objets de formulaire ? Les avantages attendus :

Les prétendus avantages incluent :

• Découplage : Séparer la logique métier des contrôleurs et des modèles.
• Afficher les aides : Fournir des méthodes d'assistance pour les éléments de formulaire complexes (par exemple, des options pour sélectionner des champs).
• Adhésion à la convention Rails : Simplification des formulaires complexes sans mappage direct sur des modèles ActiveRecord uniques.

Cependant, l'absence d'une définition claire conduit au premier problème majeur : une mauvaise communication. Lorsque vous rencontrez des objets de formulaire dans une base de code, il n'est pas clair lequel de ces rôles (ou une combinaison de ceux-ci) ils remplissent.

Essentiellement, les objets de formulaire visent à refactoriser la complexité du code en centralisant les responsabilités, généralement au sein des couches modèle et/ou contrôleur. Mais cela conduit au deuxième problème : ballonnement involontaire.

L'inconvénient : l'anti-modèle « objet de forme grasse »

Envisagez une implémentation commune :

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

Cette approche apparemment simple masque un problème important. L'API publique de l'objet formulaire (new, valid?, save! et sa présence dans la vue) révèle qu'il gère :

• Analyse des paramètres : Comprendre et transformer les paramètres de la requête.
• Validation :Connaître les types de paramètres et les règles de validation (logique métier).
• Persistance : Savoir créer et conserver des données (interaction avec la base de données).
• View Logic : Contient potentiellement une logique liée à la vue (méthodes d'assistance pour les éléments de formulaire).

Cela viole le principe de responsabilité unique. L'objet formulaire devient un référentiel pour diverses préoccupations, attirant davantage de responsabilités au fil du temps (assistants de visualisation supplémentaires, règles de validation, etc.). Il évolue vers un « objet de forme grasse », reflétant les problèmes mêmes qu’il était censé résoudre.

Le troisième problème : la redondance

Une préoccupation plus importante est que ces responsabilités sont souvent déjà assumées par d'autres composantes :

• Persistance : C'est la responsabilité du modèle. Déléguez au modèle au lieu de reproduire ses fonctionnalités.
• Logique métier : Utilisez des objets de service pour une logique métier complexe.
• Validation d'entrée : Utiliser des bibliothèques de validation (ActiveRecord::Model, Scrivener, dry-schema).
• Afficher les assistants : Utilisez des modèles de vue ou des présentateurs.

Dans les applications de taille moyenne à grande, ces composants existent probablement déjà. L’introduction d’objets de formulaire dont les responsabilités se chevauchent ajoute une complexité inutile et une ambiguïté architecturale. La complexité doit être abordée directement et non masquée.

Une alternative proposée : une approche plus modulaire

Une approche plus structurée utilise des objets dédiés pour chaque responsabilité :

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

Avantages de cette approche :

• Responsabilités claires : Chaque objet a un objectif unique et bien défini.
• Testabilité : Plus facile et plus rapide pour tester des composants individuels.
• Maintenabilité : Structure du code et maintenabilité améliorées.

Conclusion :

Les objets de formulaire ne sont pas intrinsèquement mauvais. Ils peuvent être bénéfiques lorsqu’ils sont utilisés judicieusement. Cependant, leur définition vague et leur tendance à l’excès de responsabilité méritent un examen attentif. Avant d'introduire ou d'utiliser un objet de formulaire, déterminez si les composants existants gèrent déjà les fonctionnalités requises. Si la complexité existe, intégrez-la à travers des objets bien définis et à usage unique plutôt que de la cacher dans un « objet forme » mal défini.

Articles liés (reformatés pour plus de clarté) :

• 7 modèles pour refactoriser les modèles Fat ActiveRecord
• Rails disciplinés : techniques et modèles d'objets de formulaire — Partie 1
• Modèles RubyOnRails essentiels — partie 4 : Objets de formulaire
• Objets de formulaire ActiveModel
• Comment garder vos contrôleurs minces avec des objets de formulaire
• Utilisation d'objets de formulaire dans Ruby on Rails
• Validation des objets de formulaire
• Création d'objets de formulaire avec ActiveModel
• Refactorisez votre code avec des objets de formulaire

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!