Non pas d'accord...Envoyé par BenoitM
Y a une très bonne réponse ici : http://stackoverflow.com/questions/1...-mvc-viewmodel
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Non pas d'accord...
Y a une très bonne réponse ici : http://stackoverflow.com/questions/1...-mvc-viewmodel
Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.
Twitter Blog Mon site
Mon article sur l'agilité
je sais que c'est une architecture conçu pour WPF
MVVM: Model-View View-Model
mais ma question y a t il une différence majeure entre le MVC et MVVM?
je connais déjà une, l'absence du controller dans le MVVM non??
As-tu lu le contenu du lien que j'ai posté ?
Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.
Twitter Blog Mon site
Mon article sur l'agilité
ah non je vien de le lire.
si j'ai bien compris en MVVM le datbinding entre la vue et le model remplace le controlleur??
mon anglais est pas terrible.
mais ce que j'ai compris c'est grace au (WPF) binding qui permet d'allerger le controler donc pas grand chose de différent dans le principe
(part contre ca soulage énormement le coding)
Je ne suis qu'un pauvre débutant alors ne frappez pas si mes idées ne sont pas bonnes
Pour développer un peu sur la comparaison MVC / MVVM...
Dans MVVM, le VM joue à la fois le rôle de modèle et de contrôleur. L'UI n'est donc plus constituée que de deux entités, contre trois dans MVC. En effet, contrairement à MVC, le modèle M de MVVM n'est pas une part de l'UI : dans une couche N-tiers, le modèle est la couche inférieure à l'UI.
En général (mais pas toujours), M, V et VM sont traités comme des couches, ordonnées comme suit : V-VM-M : autrement dit V n'échange qu'avec VM, jamais directement avec M. Dans MVC, les trois entités communiquaient entre elles, elles ne sont jamais traitées comme des couches.
La VM associée à une vue est fréquemment composée de très nombreux objets : des objets implémentant INotifyPropertyChanged pour le binding, des commandes et des convertisseurs. Par exemple, pour une vue affichant une liste de clients avec quelques champs pour filtrer les résultats, on pourra avoir un ListeVM offrant des propriétés bindables représentant les filtres et une liste de clients à afficher. Mais chaque client sera à son tour un objet implémentant INotifyPropertyChanged et appelé ClientVM.
Est-ce que c'est vraiment plus court et simple à coder ? Bof. Mais c'est sans aucune doute élégant et agréable à manipuler.
Dans MVVM il n y a pas un controller proprement dis.
La ViewModel est là pour adapter le contenu du model à la View. Les interactions sont présentes dans la ViewModel sous forme de Commande et le databinding de WPF gère l'actualisation de l'affichage dans la View.
Du coup la View n'est pas sensé accédé directement au Model au contraire de MVC.
Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.
Twitter Blog Mon site
Mon article sur l'agilité
Aucune.
Imagine un monde de développeurs où tu te dis :
- J'ai des données
- J'ai des traitements avec ces données
- J'ai des utilisateurs de ces données
- J'ai des utilisateurs de ces traitements
L'un des principaux dans les applications classiques, c'est l'IHM :
Par exemple, quand je rentre le code d'un produit et une quantité, on me calcule un prix.
Longtemps, on a mélangé le code de l'événement cliquer sur le boutton avec la fonction réelle derrière, liée au donnée.
Un jour, on a détaché l'accès à la donnée des écrans. Cela s'est appelé "Modéle Vue". C'est à dire qu'il y avait une classe pour la fenêtre et une classe qui faisait les appels SQL.
Problème, il reste les événements : c'est à dire que ce sont les événements de la vue (bref l'écran) qui conditionne l'usage de la donnée (la classe sql souvent).
Comment faire ?
En créant une couche intermédiaire!
En se complexifiant dans le temps, toutes les applications ne sont pas client / serveur, toutes les applications ne sont pas liées à la donnée, toutes les perceptions peuvent être différentes et des principes fumeux ont émergé :
MVC, MVP, MVVM....
Dans tous les cas; il s'agit simplement de dire :
- J'ai une classe qui fait l'affichage et produit des évènements
- J'ai une classe qui contractualise ces évènements et leur routage
- J'ai une classe qui représente la données nécessaire au traitement des évènements.
Dans la réalité et dès que les application sont distribuées, on se rend compte qu'il faut un modèle non lié au données (d'où le MVVM d'ailleurs) ou aussi DTO ou value object. Il est donc nécessaire à ce modèle parfois de se synchroniser avec des données, et là le bonheur de l'objet c'est que c'est récursif.
Donc on fait une Vue du modèle au dessus du modèle, synchronisé par un tiers qui contrôle, avec des évènements gérés par une Vue qui binde la vue modèle et produit des évènements qui sont interceptés par le contrôleur qui resynchronise la vue avec le modèle de la vue. Arrivé là, le bon sens devrait te dire : je me suis trompé. Tu auras du ajouter dans ton code des interfaces à foison, de l'IOC, de l'AOP, de la réflexion, de l'abstraction. Tu as besoin de 1500 lignes de codes pour créer une fenêtre MDI, une barre de navigation et et un explorer.
Car tu as pensé moderne et objet : Et si demain je change de framework IHM ? Et si demain je change de SGBD ? Et si demain je change d'ORM ? Et si demain je change de conteneur ? ...
Le pb de tout cela est qu'on arrive souvent à des frameworks sans souplesse, ce qui est pratique quand on veut juste faire du CRUD, mais devient pénible quand on veut faire des choses plus complexes et maintenables.
N'oublies juste jamais que si tu ne fais pas la maintenance d'une partie du code, tu feras la maintenance d'un framework, et qu'utiliser un framework avant de savoir EXACTEMENT ce qu'il faut faire, c'est comme qui dirait une petite indirection.
La réalité est que tu peux faire une application sans te conformer à tout cela, ce sont des principes très théoriques. L'idée est toujours d'avoir le moins de dépendance entre les couches (de toi à moi, la faible dépendance dans une application ça coûte en perfs aussi) et de les rendre testables.
Donc c'est souvent le gloubiboulga théorique, et en pratique un plat de spaghetti en framework. Mais si déjà tu ne fais pas la différence entre tous, c'est que tu as compris!
Ah parce que ne pas structurer et pas appliquer la séparation des préoccupations, évite le plat de spaghetti et ne pas tester facilité la maintenabilité...La réalité est que tu peux faire une application sans te conformer à tout cela, ce sont des principes très théoriques. L'idée est toujours d'avoir le moins de dépendance entre les couches (de toi à moi, la faible dépendance dans une application ça coûte en perfs aussi) et de les rendre testables.
Donc c'est souvent le gloubiboulga théorique, et en pratique un plat de spaghetti en framework. Mais si déjà tu ne fais pas la différence entre tous, c'est que tu as compris!
Beaucoup de critique, mais tu dis jamais comment il faut procéder d'après toi, avec ou sans patterns on peut faire de la merde, mais si on cherche pas à faire de la qualité on en aura pas ça c'est une certitude.
Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.
Twitter Blog Mon site
Mon article sur l'agilité
Si je te la donne : quand tu sais EXACTEMENT ce que tu dois faire, tu sais à priori exactement de quoi tu as besoin.
S'il faut un design pattern pour expliquer aux développeurs que mettre du code métier dans les écrans pose des pb de maintenance et que c'est crade, on peut le faire.
S'il faut crier au génie parce que quelqu'un à mis un nom devant le procédé, on peut aussi.
D'après moi, soit on pond un Framework destiné aux vues en fonction de la destination du développement (bref développement adapté) et pour le réussir il faut savoir EXACTEMENT ce que doit faire le développement et dans certains cas on peut le ré-utiliser, soit on pond un framework générique qui sous prétexte d'être testable et générique finira par devenir une dette technologique.
Moi c'est ça qui me gêne. C'est la pléthore de Framework qui te disent que tu feras mieux des applications qui font CRUD. Ce qui n'est pas la problématique du dev client, qui est plutôt d'orchestrer la présentation de fonctionnalités métiers pas toujours aussi triviale que d'acheter 50 bouteilles dans Northwind.
Et c'est valable pour tout. C'est valable pour ceux qui prennent des ORMs sans jamais s'en être servi et finissent bloqués par l'usage, ceux qui prennent des conteneurs et finissent débordés par les contextes et les fichiers XML, ceux qui utilisent de l'AOP runtime et se demandent pourquoi ils ont des pb de perfs...
La solution générique et générale n'existe pas. Après le tout est de savoir s'il faut se conformer à la doctrine d'une communauté, ou se conformer à un objectif réel de développement.
Tu peux séparer tous les propos d'une application, ça signifiera jamais que tu avais capté le propos de l'application, et tu as potentiellement séparé des propos inutiles.
La qualité essentielle d'un dev c'est sa conception à l'origine, c'est à dire sa modélisation. La plomberie pour orchestrer après, c'est accessoire. Car tant que la modélisation est juste, le fait de le faire en Web, en sl, en WPF, en distribué ou en c/s; c'est de la technique. C'est juste une étape après.
Tu dis que ce sont des principes très théoriques et tu proposes une solution utopique, attendre de savoir EXACTEMENT ce qu'on doit faire... Mais le besoin est changeant, évolutif la plupart du temps.
L'utilisation de framework sert à capitaliser sur des solutions approuvées, on peut pas non plus refaire la roue à chaque fois. Bien sûre qu'il faut minimiser leur utilisation et minimiser leur impact...D'après moi, soit on pond un Framework destiné aux vues en fonction de la destination du développement (bref développement adapté) et pour le réussir il faut savoir EXACTEMENT ce que doit faire le développement et dans certains cas on peut le ré-utiliser, soit on pond un framework générique qui sous prétexte d'être testable et générique finira par devenir une dette technologique.
En plus, je ne comprends pas ton association systématique entre pattern, principe et utilisation d'un framework... On peut appliquer les principes SOLID sans utiliser le moindre framework.
Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.
Twitter Blog Mon site
Mon article sur l'agilité
Qu'est ce que tu appelles un besoin changeant ? Qu'est ce qui peut changer tellement dans une application qu'elle force une refonte complête de l'interface utilisateur ? (sorti de projets de "refonte" et autres "portages")
Contrairement au mythe vendu actuellement il y a des gens qui font de l'informatique qui comprennent parfaitement les sujets qu'ils traitent. Donc ce que tu penses être une utopie, c'est pour ça que je suis payé aujourd'hui. Parce que je comprends parfaitement la matiére que je dois coder. Comment je dois la coder ça m'appartient, et ça ne reste qu'une étape.
Je vais t'epargner les chiffres de projets informatiques qui échouent...
Mais au delà de ça il y a des projets r&d, le Web, tomber sur des clients à l'humeur changeante... A quelles types d'utilisateur tu es confronté ? Industrie ? Chez les éditeurs on se retrouve souvent a changer face a la confrontation aux clients, face à un premier prototype...
Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.
Twitter Blog Mon site
Mon article sur l'agilité
Je comprends que fasse au nombre de projets qui échouent dans les grandes boites ce soit tentant. Maintenant les projets qui échouent en info ne sont pas révélateurs du développement et de sa réalité.
Tout ce que tu dis est parfaitement vrai, mais je ne vois pas en quoi ça apporte des réponses à la relation avec le client. La plupart de mes clients se foutent de savoir si j'utilise WF, WPF, Winform, MVC, MVP, MVVM. Ils regardent une finalité. Si je me loupe dans ma compréhension du client et que je n'ai pas fait qqch qui va dans le sens de mon client, le pb est chez moi, et que mon code soit propre ou crade, ça ne change rien.
Totalement d'accord avec toi. Mais cela reste faux si le client possède un chef de projet technique (les chefs de projets ne sont pas toujours fonctionnels). Si ce type de chef de projet est intelligent, qu'il soit nul dans la technologie que tu vas utiliser, il te demandera comment tu comptes t'en prendre avec ce que la société t'as demandée de développer. Pourquoi ? Bah! Pour pouvoir expliquer à ceux qui viendront après toi que tels ou tels outils, architecture logicielle ou physique a été utilisé parce que bla bla bla
Ça ne change rien ? Vraiment ?
Disant que la plupart des projets, se font en équipe (au moins 2 personnes) et que la plupart des projets voient plusieurs équipes... Ca ne change rien que le code soit crade, pour la maintenance ? L'évolutivité ?
Le client sous estime l'importance de la qualité dans le développement logicielle et c'est un tord de mon point de vue. Et c'est à nous de lui prouver que sur des grands projets, les coûts de maintenance sont les plus importants et par conséquents un code testé et maintenable, n'est pas une simple option
Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.
Twitter Blog Mon site
Mon article sur l'agilité
C'est une considération économique : si un client paye pour le service minimum; il a le service minimum. S'il paye pour avoir de la qualité, il aura de la qualité.
C'est un tautologie soit, mais c'est aussi une réalité. Et l'empilage de Frameworks et de concepts n'ont absolument rien à voir avec la qualité.
La vraie difficulté ce n'est pas de rendre un développement testable; c'est de savoir quoi tester, d'implémenter les tests et de les maintenir.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager