activerecord comme modèle, est-ce une bonne idée ?

Question

Récemment, grâce à la popularité des rails, de nombreuses personnes ont commencé à utiliser activerecord comme modèle.cependant, avant d'entendre parler de rails (mon groupe de pairs n'était pas fan des trucs open source, on nous enseignait dans une école .NET...) et pendant que je faisais mon projet de dernière année, j'ai trouvé cette définition d'un modèle

Le modèle représente les données d'entreprise et les règles métier qui régissent l'accès et les mises à jour de ces données.Souvent, le modèle sert d'approximation logicielle d'un processus du monde réel, c'est pourquoi des techniques simples de modélisation du monde réel s'appliquent lors de la définition du modèle.

cela ne dit pas que le modèle doit représenter une table comme le fait activerecord.Et normalement, au sein d'une transaction, il peut être nécessaire d'interroger quelques tables non liées, puis de manipuler les données de différentes tables...donc si activerecord est utilisé comme modèle, alors l'un ou l'autre devra insérer tout le code logique dans le contrôleur (ce qui est assez populaire dans certains frameworks php), ce qui rend difficile le test ou le piratage du modèle activerecord afin qu'il effectue une opération de base de données sur non seulement la table à laquelle il correspond, mais également d'autres tables associées...

alors, qu'y a-t-il de si génial à abuser (à mon humble avis) d'activerecord comme modèle dans un modèle architectural MVC ?

Answer 1

Martin Fowler a décrit ce modèle dans Patterns of Enterprise Application Architecture avec deux autres modèles ou architectures.Ces modèles conviennent à différentes situations et à différents niveaux de complexité.

Si vous souhaitez uniquement des choses simples, vous pouvez utiliser Transaction Script.Il s'agit d'une architecture que vous avez vue dans de nombreuses anciennes pages ASP et PHP, où un seul script contenait la logique métier, la logique d'accès aux données et la logique de présentation.Cela s’effondre rapidement lorsque les choses se compliquent.

La prochaine chose que vous pouvez faire est d'ajouter une certaine séparation entre la présentation et le modèle.Ceci est un enregistrement actif.Le modèle est toujours lié à la base de données mais vous avez un peu plus de flexibilité car vous pouvez réutiliser votre modèle/accès aux données entre les vues/pages/quoi que ce soit.Ce n'est pas aussi flexible qu'il pourrait l'être, mais en fonction de votre solution d'accès aux données, cela peut être suffisamment flexible.Les frameworks comme CSLA dans .Net ont de nombreux aspects de ce modèle (je pense qu'Entity Framework ressemble aussi un peu trop à ça).Il peut encore gérer beaucoup de complexité sans devenir ingérable.

L'étape suivante consiste à séparer votre couche d'accès aux données et votre modèle.Cela nécessite généralement un bon mappeur OR ou beaucoup de travail.Donc tout le monde ne veut pas suivre cette voie.De nombreuses méthodologies telles que la conception pilotée par domaine autorisent cette approche.

Tout est donc une question de contexte.De quoi avez-vous besoin et quelle est la meilleure solution.J'utilise même parfois le script de transaction pour un simple code à usage unique.

Answer 2

J'ai dit à plusieurs reprises qu'utiliser Active Record (ou ORM qui est presque le même) comme Business Models n'est pas une bonne idée.Laisse-moi expliquer:

Le fait que PHP soit Open Source, gratuit (et toute cette longue histoire...) lui fournit une vaste communauté de développeurs déversant du code dans des forums, des sites comme GitHub, du code Google, etc.Vous pourriez considérer cela comme une bonne chose, mais parfois, cela a tendance à ne pas être « si bon ».Par exemple, supposons que vous soyez confronté à un projet et que vous souhaitiez utiliser un framework ORM pour faire face à votre problème écrit en PHP, eh bien...tu en auras beaucoup options à choisir:

• Doctrine
• Propulser
• QCodo
• Torpeur
• Haricot rouge

Et la liste continue encore et encore.De nouveaux projets sont créés régulièrement.Imaginez donc que vous avez construit un framework complet et même un générateur de code source basé sur ce framework.Mais vous n'avez pas placé de cours de commerce parce que, après tout, "pourquoi réécrire les mêmes cours ?".Le temps passe et un nouveau framework ORM est publié et vous souhaitez passer au nouvel ORM, mais vous devrez modifier presque toutes les applications clientes en utilisant une référence directe à votre modèle de données.

En fin de compte, Active Record et ORM sont censés se trouver dans la couche de données de votre application. Si vous les mélangez avec votre couche de présentation, vous pouvez rencontrer des problèmes comme cet exemple que je viens de présenter.

Écoutez les sages paroles de @Mendelt :Lisez Martin Fowler.Il a publié de nombreux livres et articles sur la conception OO et publié de bons documents sur le sujet.Aussi, vous voudrez peut-être examiner Anti-modèles, plus précisément dans Verrouillage du fournisseur, c'est ce qui se produit lorsque nous rendons notre application dépendante d'outils tiers.Finalement, j'ai écrit ce article de blog parlant du même problème, donc si vous le souhaitez, consultez-le.

J'espère que ma réponse a été utile.

Answer 3

L'avantage d'utiliser Rails ActiveRecord comme modèle dans MVC est qu'il vous offre un ORM (Object Relational Mapper) automatique et un moyen simple de créer des associations entre les modèles.Comme vous l'avez souligné, MVC peut parfois faire défaut.

Par conséquent, pour certaines transactions complexes impliquant de nombreux modèles, je suggère d'utiliser un présentateur entre votre contrôleur et vos modèles (Modèle de présentateur Rails).Le Presenter regrouperait vos modèles et votre logique transactionnelle et resterait facilement testable.Vous voulez absolument vous efforcer de conserver toute votre logique métier dans vos modèles ou présentateurs, et en dehors de vos contrôleurs (Contrôleur maigre, gros modèle).