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!

Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

Video Face Swap
Échangez les visages dans n'importe quelle vidéo sans effort grâce à notre outil d'échange de visage AI entièrement gratuit !

Article chaud

Outils chauds

Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Sujets chauds

Des questions et des solutions fréquemment posées pour l'impression de billets thermiques frontaux pour le développement frontal, l'impression de billets est une exigence commune. Cependant, de nombreux développeurs mettent en œuvre ...

JavaScript est la pierre angulaire du développement Web moderne, et ses principales fonctions incluent la programmation axée sur les événements, la génération de contenu dynamique et la programmation asynchrone. 1) La programmation axée sur les événements permet aux pages Web de changer dynamiquement en fonction des opérations utilisateur. 2) La génération de contenu dynamique permet d'ajuster le contenu de la page en fonction des conditions. 3) La programmation asynchrone garantit que l'interface utilisateur n'est pas bloquée. JavaScript est largement utilisé dans l'interaction Web, les applications à une page et le développement côté serveur, améliorant considérablement la flexibilité de l'expérience utilisateur et du développement multiplateforme.

Il n'y a pas de salaire absolu pour les développeurs Python et JavaScript, selon les compétences et les besoins de l'industrie. 1. Python peut être davantage payé en science des données et en apprentissage automatique. 2. JavaScript a une grande demande dans le développement frontal et complet, et son salaire est également considérable. 3. Les facteurs d'influence comprennent l'expérience, la localisation géographique, la taille de l'entreprise et les compétences spécifiques.

La discussion sur la réalisation des effets de défilement de parallaxe et d'animation des éléments dans cet article explorera comment réaliser le site officiel de Shiseido (https://www.shiseido.co.jp/sb/wonderland/) ...

Apprendre JavaScript n'est pas difficile, mais c'est difficile. 1) Comprendre les concepts de base tels que les variables, les types de données, les fonctions, etc. 2) Master la programmation asynchrone et les implémenter via des boucles d'événements. 3) Utilisez les opérations DOM et promettez de gérer les demandes asynchrones. 4) Évitez les erreurs courantes et utilisez des techniques de débogage. 5) Optimiser les performances et suivre les meilleures pratiques.

Les dernières tendances de JavaScript incluent la montée en puissance de TypeScript, la popularité des frameworks et bibliothèques modernes et l'application de WebAssembly. Les prospects futurs couvrent des systèmes de type plus puissants, le développement du JavaScript côté serveur, l'expansion de l'intelligence artificielle et de l'apprentissage automatique, et le potentiel de l'informatique IoT et Edge.

Comment fusionner les éléments du tableau avec le même ID dans un seul objet en JavaScript? Lors du traitement des données, nous rencontrons souvent la nécessité d'avoir le même ID ...

Problèmes de mise à jour des données dans les opérations asynchrones de Zustand. Lorsque vous utilisez la bibliothèque de gestion de l'État de Zustand, vous rencontrez souvent le problème des mises à jour de données qui entraînent des opérations asynchrones prématurées. � ...
