Où est le M dans MVC?

J'essaie de refactoriser mon application dans MVC, mais je suis bloqué sur la partie M.

Dans une application basée sur une base de données, le modèle est implémenté dans le code de l'application, non?

Mais alors, que contient la base de données - n'est-ce pas aussi le modèle?

(Je n'utilise pas la base de données comme un simple magasin d'objets - les données dans la base de données sont un actif d'entreprise).

Oui, le modèle dans le code et la base de données sont tous les deux le "modèle".

Le modèle a à voir avec ce que votre application «EST» et le contrôleur est ce qu'il «fait». Tout code traitant de la persistance directe dans la base de données est considéré comme le modèle.

Remarque: MVC est un modèle , alors ne pensez pas trop. Il est facile de se lancer dans le MVC de la bonne façon, mais en fin de compte, ce n'est qu'un état d'esprit! Cela signifie garder votre logique métier hors de la base de données et de l'interface utilisateur - c'est tout. Avant MVC, les gens mettaient la logique métier dans leurs pages Web quand elle devrait être sur le serveur, ou ils avaient un tas de scripts tirés dans la base de données faisant la logique métier avec le code de persistance. MVC a été créé pour amener les gens à réfléchir de manière à rendre leur code réutilisable, alors ne vous laissez pas trop prendre par les détails.

Trygve Reenskaug a écrit les premiers articles décrivant le modèle MVC en 1978. Le modèle dans sa description était le modèle objet représentant des objets, des phénomènes et des concepts du monde réel. Dans votre scénario d'application basée sur une base de données, le modèle est une projection de vos données. Pour le dire simplement, le modèle est les classes et leurs relations qui concernent votre application.

En pratique, il existe généralement deux modèles utilisés dans MVC, le modèle de domaine (ce qui correspond à votre base de données) et le modèle d'application (également appelé modèle d'affichage dans la terminologie actuelle). Le modèle d'application est une projection du modèle de domaine qui contient également des données spécifiques à la vue pour le rendu de la vue. Cette approche est appelée MMVC . Le contrôleur interagit directement avec le modèle de domaine et présente un modèle d'application à la vue. Dans le modèle MVVM, le modèle d'application et le contrôleur sont combinés.

1. Vous n'avez pas besoin d'une base de données pour MVC. Si votre modèle arrive à parler à la base de données, alors tant mieux. Il peut également persister dans un fichier plat ou ne pas persister du tout.

2. Le modèle est l'endroit où les données sont stockées en mémoire dans votre application. Vous voudrez également utiliser le modèle pour effectuer des calculs et des validations sur ses données. Par exemple, vous disposez d'un modèle FinancePayment, avec des propriétés telles que le taux d'intérêt, la durée et le principe. Vous pouvez ajouter une méthode getMonthlyPayment () à votre modèle pour calculer le paiement mensuel. Vous ne voudriez pas faire cela dans le contrôleur ou la vue.

3. La vue doit être raisonnablement stupide, n'ayant aucune logique du tout, ou utilisant uniquement une simple liaison de données (voir Modèles de vue passive et de contrôleur de supervision sur le site de Martin Fowler ). La vue déclenche des événements lorsque l'utilisateur fait des choses, comme cliquer sur un bouton.

4. Le contrôleur est responsable de la gestion des événements (exécuter du code lorsque l'utilisateur clique sur le bouton Enregistrer), et de définir les propriétés du modèle, et de dire au modèle de se charger et de se sauvegarder (si vous utilisez la persistance). Le contrôleur ne doit pas effectuer de calculs sur les données du modèle. Cependant, dans le contrôleur, vous pouvez effectuer des calculs au nom de la vue, tels que "si model.profit () <0 then widget.colour = 'red'"

5. Vous devriez pouvoir basculer vers une version en ligne de commande de votre application sans modifier les modèles et sans perdre la fonctionnalité des modèles.

une. Vous devriez probablement pouvoir passer à une version mobile de votre application (par opposition à une version de bureau) en changeant uniquement les vues (et non les contrôleurs ou les modèles). Vous devriez pouvoir tester à l'unité vos modèles et contrôleurs sans infrastructure de test GUI.

Le modèle est le code qui a une connexion à V et C dans le frontend, et au stockage persistant (peut être n'importe quoi, des fichiers aux bases de données SQL / NoSQL) dans le backend. Ce n'est pas seulement le code qui se charge de db et stocke dans db (qui est l'un des malentendus du modèle), c'est le code qui fait en fait tout le travail de "domaine" - sélectionne, filtre, modifie, calcule, décide de la Les données. Comprend toute la logique non UI de l'application.

Adopter une vision très simpliste et idéaliste.

Le modèle est généralement considéré comme un modèle du domaine (en gros, l'entreprise), et non comme un modèle des données. Ceux - ci peuvent sembler similaires, mais ils ne sont pas complètement liés les uns aux autres.

La vue doit être un modèle du front-end de l'application et le contrôleur doit être un modèle du flux d'une vue à l'autre.

La logique métier doit être entièrement encapsulée dans le modèle, que ce soit dans la base de données ou dans le code. Bien qu'une logique métier puisse être répétée dans la vue ou le contrôleur, pour diverses raisons, il devrait être possible (et sûr) de supprimer complètement ces deux composants et de mettre un frontal différent à sa place.

À ma connaissance, MVC n'est que la description du modèle architectural de votre application client. L'image ici dans Wikipedia montre juste ceci:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Bien sûr, lorsque certaines parties de votre application sont implémentées dans des "procédures stockées", le code de cette base de données peut également faire partie du modèle, voire du contrôleur (selon ce que fait le code). Mais si ce n'est pas le cas, alors la base de données est clairement "en dehors de MVC", comme vous l'avez dit.

But then, what is in the database -- is that not also the model?

Non ça ne l'est pas. " Le modèle gère le comportement et les données du domaine d'application". Souvent, le modèle se connecte à une base de données oui, mais ce n'est en aucun cas une exigence. Le modèle est une nouvelle couche entre votre application et la base de données. Le backend peut être un ensemble d'objets Mock, XML ou tout autre élément prenant en charge la persistance des données.

En découplant les couches, vous vous donnez une plus grande flexibilité pour utiliser de meilleures pratiques de test unitaire, rendez le code plus facile à gérer (EG SQL est remplacé par Oracle) entre autres avantages.

Il en va de même avec le contrôleur. MVC définit le contrôleur comme un intermédiaire entre les deux couches. Aucune «couche métier» n'est définie dans MVC. Vous ajoutez plutôt la vôtre. MVC n'encapsule pas toutes les couches requises pour créer la plupart des applications. C'est juste une directive générale pour la structure de base.

Ces séparations sont essentielles pour permettre à l'inversion de contrôle de fonctionner.

La base de données est un détail d'implémentation du modèle. Le modèle doit être un modèle de domaine complet et doit combiner données et processus. La séparation doit être entre les préoccupations de différence et non entre un processus et les données liées à ce processus.

Voir également: http://martinfowler.com/bliki/AnemicDomainModel.html

C'est très simple en fait, "Model" représente l'abstraction de l'interface de données. C'est pourquoi:

• Les bases de données sont considérées comme faisant partie du modèle , mais pas le modèle lui-même
• Les modèles données peuvent provenir de bases de données, de fichiers, de services Web ou même être simulées.
• Les classes de modèle dans MVC, HMVC ou des cadres similaires doivent stocker des requêtes (voir le principe "modèle gras, contrôleur maigre" [ 1 ] [ 2 ] [ 3 ])

Et - si j'ai raison - c'est pourquoi lorsque quelqu'un se réfère à des modèles en dehors du contexte MVC, cette personne se réfère très probablement à la structure des données (c'est-à-dire le schéma ).

Je pense que le M contient de la logique et stocke des données dans DB. Le contrôleur appelle quel module sera exécuté et ce module exécutera les logiques et stockera les données dans la base de données (peut être a une couche persisent), puis ce module renvoie la valeur à V.

Le M (odel) dans le MVC devrait capturer le modèle de l'entreprise / du domaine en un seul endroit.

Cela devrait idéalement comprendre les règles commerciales du domaine ainsi que sa structure.

Idéalement, le C (contrôleur) ne doit se soucier que de la médiation des informations du modèle commercial vers la présentation (par exemple, la vue) et de la capture des entrées utilisateur de V (iew) pour initier des changements dans l'état du modèle.

La couche de base de données ne traite (ou plutôt ne devrait traiter que) de la persistance de l'état du modèle à un moment donné.

En tant que tel, ce n'est pas quelque chose qui appartient à la partie Modèle ou Contrôleur du modèle MVC, mais c'est plutôt une préoccupation complètement distincte qui peut être implémentée implicitement en persistant de manière transparente toute modification du modèle (en fonction de la façade, fournissant la interactions avec votre modèle vers le contrôleur) ou comme cela se fait le plus souvent, appelé explicitement par le contrôleur une fois qu'il a fini de faire des mutations sur le modèle.

Le modèle dans un monde idéal ne devrait contenir que la logique métier, il modélise un objet réel tel qu'une maison. Cependant, dans presque toutes les circonstances, le modèle doit conserver ses données dans un certain stockage.

Les interactions entre le modèle et les données stockées peuvent se produire sur une couche de données distincte ou directement dans le modèle, ce qui est le cas lors de l'utilisation d'un ORM (Object Relational Mapper). En d'autres termes, le modèle se connecte directement à la base de données ou transmet ses données à un autre objet "d'accès aux données" qui se connecte à la base de données.

Un ORM (Object Relation Mapper) mappe les champs de la table de base de données aux attributs de votre objet modèle, fournissant des getters et setters. Dans ce cas, il n'y a pas de couche de données distincte et le modèle est directement responsable de la persistance de ses données.

Voici un exemple Ruby utilisant ActiveRecordun ORM populaire:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Priceest un champ de la housestable qui est automatiquement détecté par ActiveRecordlequel ajoute un getter et un setter à l'objet. Quandsave est appelé, la valeur de l'attribut price est conservée dans la base de données.

De mon point de vue, le pro d'avoir une couche de données est que vous obtenez un point dans lequel vous pouvez manipuler les données avant qu'elles n'atteignent le modèle, le modèle a moins d'inquiétude, il a moins de responsabilités. Par exemple, vous devrez peut-être combiner des données provenant de plusieurs sources de données non compatibles, c'est quelque chose qu'un ORM ne peut pas facilement gérer.

Le principal inconvénient est que c'est une autre couche d'abstraction à gérer, si vous n'en avez pas besoin, ne vous embêtez pas, restez simple. Moins de pièces mobiles, moins de problèmes.

Oui, tu as raison.

(Modèle Vue Contrôleur)

Une architecture pour construire des applications qui séparent les données (modèle) de l'interface utilisateur (vue) et du traitement (contrôleur).

Dans la pratique, les vues et les contrôleurs MVC sont souvent combinés en un seul objet car ils sont étroitement liés. Selon MSDN

Le contrôleur interprète les entrées de la souris et du clavier de l'utilisateur, informant le modèle et / ou the view to change as appropriate.

Vérifiez ce schéma:

Par exemple, le code du contrôleur valide une demande de données et la renvoie dans une vue. Les objets du contrôleur de vue sont liés à un seul modèle; cependant,a model can have many view-controller objects associated with it.