Dans le modèle MVC, le contrôleur est un pipeline et le modèle est le processeur. Mais souvent, le contrôleur aura besoin de contenus différents provenant de différentes tables. De cette façon, il y aura de nombreuses fonctions dans le modèle telles que get_name, get_info, get_id, etc. qui pourront être complétées avec une seule requête. Cela semble encombrant. En fait, il serait bien d'écrire une requête dans laquelle le contrôleur doit être utilisé, mais cela enfreint les règles de MVC.
L'idée actuelle est de mettre les fonctions les plus utilisées dans le Modèle et de laisser les fonctions fragmentaires dans le Contrôleur.
S'il vous plaît donnez-moi vos avis ~
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
C mince, M gras, C ne doivent pas dépasser 15 lignes
En fait, le problème que vous avez mentionné peut être résolu par de nombreux frameworks, c'est-à-dire la fonction d'enregistrement actif, qui génère dynamiquement des instructions de requête basées sur le code. Elle a d'abord été promue dans le framework rails et progressivement implémentée dans d'autres langages. Par exemple
En fait, si votre framework prend en charge l'enregistrement actif, nous n'avons pas besoin d'écrire une ligne de code dans le modèle pour une requête aussi simple basée sur la clé primaire. La classe de base du modèle est assemblée dans une instruction de requête appropriée basée sur la clé primaire. le nom de la méthode que vous appelez et vous renvoie les résultats de la requête.
Je ne sais pas quel langage vous utilisez, mais actuellement, pratiquement tous les langages de script ont une implémentation d'enregistrement active. Vous pouvez implémenter cette fonction dans votre propre projet, ce qui apportera également des avantages au développement ultérieur.
Les problèmes qui peuvent être contraints dans le code sont plus efficaces que de stipuler certains principes de conception, car vous ne pouvez pas garantir que chaque développeur a le même niveau.
Vous pouvez vous référer au livre de modèles de Fowler, au script de transaction, au module de table et aux trois styles de modèle de domaine.
Je ne sais pas comment CI implémente l'enregistrement actif, mais la petite fonction que vous avez mentionnée est une méthode magique utilisée dans de nombreuses implémentations d'enregistrements actifs PHP, ou le générateur de code le génère automatiquement pour vous, vous n'avez donc pas besoin de l'écrire vous-même .
Par exemple, l'enregistrement actif est implémenté dans la doctrine comme ceci : S'il existe une table foo avec les champs bar1, bar2 et bar3, la doctrine générera directement quatre fichiers selon le schéma de la table : FooTable.class.php, FooTableBase.class. php , Foo.class.php, FooBase.class.php. Dans les deux fichiers de base, il y aura une série de getters et setters générés automatiquement tels que getBar1(), setBar1($param). Le fichier de base ne peut pas être modifié par les programmeurs eux-mêmes, il changera à mesure que le schéma change. La classe non-base hérite directement de la classe de base, elle a donc l'air beaucoup plus propre
Mettez votre logique d'application dans le modèle
Faisons la superposition. Le contrôleur est responsable de la logique de contrôle au niveau de la page
.。 。 。 。 。 。 。 。 。 。