Comprendre le MVC
AliGator
Membre, Modérateur
Connectez-vous ou Inscrivez-vous pour répondre.
AliGator
Membre, Modérateur
Réponses
Bravo, je trouve que ça explique clairement le concept.
L'exemple avec le carnet d'adresse est très bienvenu. Cela permet de commencer à s'approprier la théorie par une application pratique simple, et c'est pas du luxe!
Je pense que ça fait une bonne introduction* et qu'après on peut plus facilement aller lire les liens que tu donnes à la fin, pour répondre aux questions qui peuvent rester, comme "c'est où que ça se passe pour que la vue sache qu'il est temps de répercuter les changements du model" ou "où se fait le traitement des interactions utilisateurs qui veulent modifier le model".
Merci pour ceux qui ne jonglent pas encore avec les design pattern (moi par exemple)
* d'ailleurs heu, j'ai un doute sur ta première phrase.... ça se dit "introduire un concept à ceux qui ne le connaissent pas" ? ça fait mal?
http://conception.developpez.com/cours/?page=archi-cat#dp-theorie
dont KVO KVC Delegate pour COCOA
mais aussi de façon générale MVC Façade
Pont
Sépare et découple une abstraction et son implémentation permettant à chacune d'évoluer indépendamment.
Décorateur
Ajoute des fonctionnalité à un objet de manière entièrement dynamique. Parfois plus efficace que l'héritage, il permet d'étendre les capacités de plusieurs classes sans en modifier les sources.
Singleton
S'assure de l'unicité d'une instance de classe et évidemment le moyen d'accéder à cette instance unique.
Proxy
Objet léger qui remplace le véritable objet complet.
Etat
Permet de modifier le comportement d'un objet lorsque son état est modifié. Tout est mis en place pour donner l'impression que l'objet lui-même a été modifié.
Adaptateur
Encapsule les accès à une API qui ne correspondatait pas à vos normes ou a vos besoins...
Facade
Unifie et simplie l'interface d'un sous système cohérent et éventuellement autonome. Forme donc un point d'entrée simplifié dans une API.
Monteur
Dissocie le processus de construction d'un objet complexe de la structure de représentation de cet objet.
Kit
Fournit un processus de construction de familles d'objets apparentés et cohérents.
Composite
Permet de modifier le comportement d'un objet lorsque son état est modifié. Tout est mis en place pour donner l'impression que l'objet lui-même a été modifié.
En cours de C#, j'ai eu le droit à l'explication de la Presentation Layer/Business Layer/Data Access Layer...
Je me demandais s'il y avait des différences entre la conception PL-BL-DAL présentée par M$ et MVC. Car d'après ce que j'ai compris, cela se ressemble beaucoup...
Si ce n'est pas le cas, est-ce juste un choix de dénomination différente pour pas faire comme le voisin ?
La différence essentielle que je vois entre MVC et MVP est que dans le MVP, le présenter n'est en charge que de piloter la vue, normalement au travers une "interface" au sens POO (soit un @protocol au sens Objective-C), permettant un couplage faible entre Presenter et Vue. Alors que dans MVC le Controller connaà®t l'organisation de la vue.
Par exemple dans MVC on aura dans le Controller pour piloter notre PersonView affichant les détails d'une personne, un pointeur vers un [tt]UILabel* nameLabel[/tt], et le Controller va appeler des trucs comme [tt]nameLabel.text = model.currentPerson.name[/tt].
Dans MVP, on aura plutôt si je dis pas de bétises, un @protocol IPersonView, qui exposera une @property name; La vue PersonView se conformera au protocole IPersonView et implémentera donc le setter de la @property name par [tt]-(void)setName:(NSString*)newName { nameLabel.text = newName; }[/tt].
Et du coup le presenter ne va pas directement avoir accès au nameLabel de la vue, mais va uniquement avoir accès à un objet [tt]id<IPersonView> view[/tt] pour piloter la vue, et va faire [tt]view.name = model.currentPerson.name;[/tt].
Avantage, si le nom n'est plus un UILabel plus tard mais un UITextField ou autre, le @protocol ne va pas changer et le presenter sera identique, il y a juste à changer la vue. Alors que dans MVC si la vue change, faut adapter le Controller.
Mais bon, rien que ça tu vois que MVC et MVP sont deux design patterns très proches mais avec quelques différences. Donc PL-BL-DAL ça doit encore en être un autre, pour lequel même si tu retrouves des éléments communs à MVC, ne se sont pas les mêmes pour autant.