J'ai récemment lu un texte disant que le modèle MVC décrit les couches dans une application. Mais personnellement, je vois MVC montrant plusieurs rôles clés dans une application.Le motif MVC décrit-il des rôles ou des calques?
Quel est le meilleur mot, couche ou rôle, pour décrire les trois parties principales de MVC?
Pourquoi pas les deux? Je le vois comme 3 couches distinctes implémentant 3 rôles différents.
Vous ne pouvez pas comparer ces deux mots, car ils décrivent différents concepts. Pour moi, une couche est quelque chose d'opaque qui offre certaines fonctions que je peux utiliser pour faire des choses. Par exemple, une bonne couche matérielle pour un émetteur sans fil me donnerait juste une fonction d'envoi et une fonction de réception (basée sur des octets, par exemple), cachant tous les détails laids et moche de moi.
Un rôle est un comportement d'un objet. Par exemple, une transformation dans l'un de mes compilateurs va prendre un arbre de syntaxe abstraite et retourner un arbre de syntaxe abstraite ou une affection dans mon projet actuel va prendre une différence d'état et retourner une différence d'état spécifiquement modifiée. Cependant, avec ces deux définitions, je ne vois pas le besoin de choisir un seul terme "correct" et de graver l'autre comme faux, car ils ne sont pas en conflit. Une partie d'une couche a un certain rôle, et un ensemble d'objets conformes à certains rôles forment une couche. Certes, le contrôleur forme une certaine couche entre l'interface utilisateur et le modèle (au moins pour l'entrée), cependant, ot a également un rôle - il transforme certains événements en certains autres événements (et donc, c'est une sorte d'adaptateur).
Je pense que les rôles sont une meilleure description. La vue et le contrôleur sont tous deux dans la même "couche" et généralement le modèle est décrit comme une couche mais est utilisé entre les couches.
Habituellement mes applications sont centrées autour du modèle de domaine avec des choses comme la présentation, la persistance et le fichier-io qui l'entoure. Penser à une architecture en couches ne fonctionne pas vraiment pour moi.
Je pense que l'une ou l'autre peut raisonnablement être argumentée, mais je pense que la description des parties en tant que "couches" est plus cohérente avec d'autres conventions, comme le OSI model. La vue, le contrôleur et le modèle se rapprochant progressivement de vos données, il s'agit davantage d'une structure en couches. Il semble que les «rôles» s'appliqueraient aux différentes parties d'une application sur la même couche.
Les couches devraient impliquer un couplage très étroit entre les ensembles de codes respectifs. MVC implique un couplage relativement étroit entre le modèle, la vue et le contrôleur. Par conséquent, si vous caractérisez cela comme un modèle de superposition, cela devient problématique en termes de définition d'une API entre les couches. Pour le faire correctement, vous devez implémenter des modèles non intuitifs. Pour cette raison, je suis d'accord avec votre tendance à le voir comme un modèle qui définit les rôles au sein d'une seule couche.
Tout est de la terminologie, mais je pense que le terme d'architecture logicielle correct serait «couche», comme dans la couche logique. Vous pouvez utiliser le terme "couche architecturale" s'il est plus clair.
La chose est, il est juste une autre façon de trancher une application: une application n-couche classique serait:
Vous pourrait avoir les couches logiques suivantes dans une application MVC simple:
Mais vous pouvez toujours parler de la « UI » et « contrôleur » ensemble comme formant la couche d'interface utilisateur - Je habituellement divisé le contrôleur cependant dans une couche distincte pour décrire et schématiser ces architectures.
MVC définit clairement ROLES. ce sont 3 rôles que vous pouvez implémenter dans n'importe quel nombre de couches. Par exemple, vous pouvez avoir un contrôleur multicouche
Je pense que vous l'avez dit le mieux jusqu'à présent. Il y a des couches de calques logiques ici, mais il semble que la fin de la journée décrive les rôles pour l'interaction. –
Rôles, pas des calques. Les calques dépendent entièrement de l'implémentation sous-jacente du modèle MVC. Par exemple, une couche de service peut être une couche unique sur une implémentation, mais elle peut avoir une couche d'accès distant de service Web et une couche de base de données (pour deux couches de service différentes) sur une autre implémentation. Le concept de calques est juste pour vous aider à l'organiser, comme le modèle, mais les calques ne sont pas aussi faciles à repérer que les motifs et les calques peuvent changer, tandis que le motif reste le même malgré les changements de calques.
Je n'ai pas de problème avec un peu de discussion. Up-voté à nouveau. – Mendelt
Non - demandant "Pourquoi?" par définition a rendu la question subjective. Enlever le "Pourquoi?" à la fin, il passe d'une question à développement à un sondage. Je ne vois pas beaucoup d'intérêt à poser la question, mais au moins maintenant, ce n'est pas tout à fait aussi ouvert. –
Ce n'est pas votre rôle de comprendre pourquoi je le demande. C'est une question valable, alors ne soyez pas si prompts à voter simplement parce que vous ne comprenez pas. –