Modèles par table de base de données?
J'utilise Cadedigniter et je me suis retrouvé dans une situation similaire où j'ai répété des méthodes de modèle. Je crée un modèle par contrôleur. Mais je créerais un modèle par table de base de données être considéré comme une bonne pratique? De cette façon les méthodes ne sont pas écrites deux fois.
Au lieu de modèle par contrôleur ou plusieurs petits modèles partagés.
Exemple Si j'ai une méthode modèle get_user ($ user_id), je pourrais l'écrire sur les utilisateurs_models.php ...
L'un des inconvénients que je vois, c'est que je devrais avoir à appeler plusieurs modèles, plutôt que de simplement contrôler_models.php.
Pourrait charger plusieurs modèles dans lesquels plusieurs méthodes peuvent ne pas être utilisées à partir d'un contrôleur affectent les performances et la vitesse? Quelle pourrait être la meilleure façon de s'attaquer à cela?
Remarque: Il existe une question similaire, mais elles ne couvrent pas le motif de modèle par table de base de données.
En général, vous devez créer vos modèles non par table ou par contrôleur, mais par objet d'entreprise. Parfois, c'est peut-être une relation de 1: 1 avec la structure de vos tables ou avec vos contrôleurs, mais pas nécessaire.
Dans votre exemple, vous pouvez avoir un users_model classe appelée à partir de plusieurs contrôleurs. C'est bien et parfois même souhaitable. Cependant, dans la plupart des cas, le users_model La classe obtiendra ses données de plusieurs tables.
Par exemple, last_login_date Propriété du users_model la classe peut (non indisible) est obtenue à partir d'un user_audit table qui a une relation une-à-plusieurs avec la table principale users.
Et je dirais que si vous avez une table SQL par objet commercial, il est fort probable que votre structure de base de données ne soit pas normalisée.
Je suis surtout d'accord avec la réponse de DIME que vous souhaitez créer vos modèles par objet d'entreprise - les problèmes que l'activité tentent de résoudre devrait piloter la manière dont vous créez les classes de modèle. En pratique, j'ai découvert que la création d'un modèle par table est un bon endroit pour commencer. Un schéma correctement conçu est susceptible d'imiter les processus opérationnels que vous devez modéliser dans le code de l'application - également appelé modèle de domaine.
L'utilisation d'une couche d'objet/cartographie relationnelle est utile, votre modèle de domaine contient les mêmes relations que le schéma de base de données sans avoir besoin d'appels répétitifs à une couche d'accès aux données. Vérifiez Eloquent pour PHP comme exemple. Le schéma et le modèle de domaine doivent être conçus pour prendre en charge les processus métier.
Cela conduit à la première partie de la réponse de Marjan Venema:
Je dis qu'un modèle par table est de recréer votre base de données dans une structure de classe. Il est connu comme un modèle anémique et considéré comme un anti-motif.
Un modèle de domaine anémique est un anti-motif. Un "modèle par table" Comme Venema suggère peut être considéré comme "recréer votre base de données", mais il est absolument incorrect de dire que cela seul est un modèle de domaine anémique.
De Martin Fowler:
Le symptôme de base d'un modèle de domaine anémique est qu'à la première rougeur, il ressemble à la vraie chose. Il existe des objets, beaucoup nommés d'après les noms de l'espace de domaine et ces objets sont connectés aux riches relations et à la structure que les modèles de domaine vrais ont. La prise vient lorsque vous regardez le comportement, et , vous réalisez qu'il n'y a pratiquement aucun comportement sur ces objets les rendant peu plus que des sacs de getters et Setteurs.
(emphase, mien)
Le facteur clé d'un modèle de domaine anémique est un manque de comportement, ou de méthodes, sur les classes de modèle de domaine.
En effet, les cours sont destinés à avoir à la fois des données et un comportement. Si vous limitez vos modèles à une seule table, où mettez-vous le code (comportement) qui doit faire face aux données et au comportement de plusieurs tables?
Encore une fois, vous pouvez, et devriez-vous mettre un comportement dans vos modèles de domaine, même s'ils ne correspondent que d'une table. Comportement qui affecte plusieurs tables affecte vraiment plusieurs objets qui arrivent à mapper dans plusieurs tables. conception de domaine axée sur le domaine est une approche du même problème Venema mentionné: "Où mettez-vous le code (comportement) qui doit faire face aux données et au comportement de plusieurs tables?"
Et la réponse est une racine globale . Martin Fowler déclare:
L'agrégat est un modèle dans la conception axée sur le domaine. Un agrégat DDD est un groupe d'objets de domaine pouvant être traités comme une unité unique. Un exemple peut être une commande et ses articles de ligne, ceux-ci Soyez des objets distincts, mais il est utile de traiter la commande (ainsi que de ses éléments de ligne) comme un seul agrégat.
(emphase, mien)
Un "groupe d'objets de domaine" peut également être considéré comme "modèles de domaine qui plantez sur plusieurs tables". Le comportement qui affecte plusieurs tables doit être défini sur la racine globale - une classe qui encapsule la "chose" qui affecte plusieurs tables ou objets:
Encore une fois, de Martin Fowler:
Un agrégat contiendra souvent des collections mutliples, ainsi que des champs simples.
Pour répondre à la question initiale de l'OP:
... créerait un modèle par table de base de données être considéré comme une bonne pratique? De cette façon les méthodes ne sont pas écrites deux fois.
Je dirais que c'est un bon endroit pour commencer, mais sachez que votre schéma et votre modèle d'objet ne doivent pas correspondre à 100%. Le modèle d'objet devrait être plus préoccupé par la mise en œuvre et l'application des règles commerciales. Le schéma devrait être plus concentré sur le stockage des données commerciales de manière modulaire et évolutive.
Un modèle par contrôleur ne serait pas une bonne pratique, bien qu'il y ait une variation du modèle appelé modèle de vue qui le fait Fixer dans la couche de contrôleur. A Afficher le modèle est une réorganisation du modèle de domaine pour adapter un certain type d'affichage, qu'il s'agisse d'une page Web ou d'une formulaire dans une application GUI.