Le modèle fait référence à la structure de données dans le cadre. Ainsi, dans le cas d`une application PHP-MYSQL, notre «modèle» sera une classe de base de données qui traite de toutes les requêtes et fonctions liées à la base de données. C`est pourquoi les deux backend et frontend peuvent partager un ensemble de classes Model, et c`est pourquoi nous n`avons pas créé de dossiers distincts dans le dossier des modèles. Exemple: dans les grands systèmes (pensez: un réseau social de taille moyenne), il peut être pragmatique de stocker des données d`authentification des utilisateurs et des données souvent consultées séparément à partir de segments de contenu plus volumineux, ce qui est rarement nécessaire. Dans ce cas, vous pouvez toujours avoir une seule classe User, mais les informations qu`il contient dépendraient de si les détails complets ont été récupérés. La vue est l`endroit où les données, demandées à partir du modèle, sont affichées et sa sortie finale est déterminée. Traditionnellement, dans les applications Web construites à l`aide de MVC, la vue est la partie du système où le code HTML est généré et affiché. La vue allume également les réactions de l`utilisateur, qui continue ensuite à interagir avec le contrôleur. L`exemple de base est un bouton généré par une vue, qu`un utilisateur clique et déclenche une action dans le Controller. Le modèle, la vue et le contrôleur sont intimement liés et en contact constant, donc ils doivent se référencer mutuellement. La figure 1 ci-dessous illustre la relation de base modèle-vue-contrôleur: il est clair pour moi que la logique d`affichage est que le code qui génère directement la sortie HTML.

Les données qui sont transformées en HTML peuvent provenir de n`importe quelle source, mais le code qui obtient ou génère ces données ne fait pas partie de la logique d`affichage. Le modèle ne génère pas de code HTML, il ne contient donc pas de logique d`affichage. De même, le modèle ne génère et n`exécute aucune requête SQL, par conséquent, il ne contient aucune logique d`accès aux données. Ceci peut se résumer comme suit: il est également important de se rappeler que la partie de vue n`est jamais donnée par le contrôleur. Comme je l`ai mentionné lors de l`examen du modèle, il n`y a pas de relation directe entre la vue et le contrôleur sans le modèle entre eux. En utilisant ce cadre, j`ai construit une application qui contient plus de 2 000 transactions utilisateur, 250 + tables de base de données et plus de 450 relations. Chaque classe de table de base de données (Model) a été générée à partir de mon dictionnaire de données et du code partagé automatiquement à partir de ma classe de table abstraite et de l`objet d`accès aux données. Chaque transaction utilisateur a été générée à partir de l`un de mes modèles de transaction et a automatiquement partagé l`un de mes scripts Controller et l`un de mes objets View.

Categories: Allgemein

Comments are closed.

Twitter updates

RSS not configured

Sponsors