J'ai besoin d'expliquer MVC à des non-programmeurs. A savoir aux managers des autres départements, dans le cadre du rapport d'avancement. L'une des choses que je fais est de refactoriser notre base de code vers la séparation MVC.

Quelle est la séparation MVC qu'ils pourraient demander? Pourquoi est-il nécessaire qu'ils demandent?

Après avoir lu une réponse assez technique comme celle-ci: Qu'est- ce que MVC, vraiment? , Je ne suis pas entièrement satisfait, car je vais parler à des non-programmeurs. Ils peuvent hocher la tête, mais ils ne comprendront probablement pas ce que c'est et pourquoi cela est nécessaire.

En réalité, je ne saisis pas complètement ce qu'est MVC autre que "la séparation des préoccupations, des devoirs, des fonctions, des classes, des blocs, des tâches, des choses, afin d'améliorer la flexibilité des modifications apportées au logiciel". La séparation de la base de données de la vue et de la vue de la logique métier à l'aide de techniques telles que les outils et techniques DI et OO est quelque chose que je considère comme une séparation MVC.

Alors la prochaine fois que vous expliquerez MVC à un non-programmeur qui a des antécédents en vente et en comptabilité par exemple, que lui diriez-vous?

Vous n'expliquez pas MVC.

Ce que vous faites, c'est expliquer qu'il s'agit d'une restructuration de la base de code.

Une restructuration qui simplifie la base de code et permet donc aux développeurs d'apporter des modifications plus rapides et meilleures aux rapports de bogues et aux demandes de fonctionnalités, avec moins de bogues.

Ils n'ont pas besoin de connaître les détails techniques, juste pourquoi cela a été fait, ce qui a été réalisé en le faisant et comment l'entreprise en profite.

En d'autres termes, parlez-leur leur langue.

Bien que j'approuve l'essentiel de la réponse d' Oded , que vous devriez expliquer les projets techniques aux chefs d'entreprise dans «leur langue», j'ai un scrupule à dire «ils n'ont pas besoin de connaître les détails techniques, juste pourquoi cela a été fait».

Si vous participez à une réunion d'examen de projet ou d'investissement avec les chefs de département et que vous déclarez "c'est ce que nous faisons", ils voudront peut-être demander "Umm ... pourquoi? Cela semble être un gros investissement de temps et d'énergie. Pourriez-vous nous expliquer un peu plus ce que vous faites et pourquoi? " Cela semble une question éminemment raisonnable. Vous ne voulez pas être pris dans une position de "Eh bien ... c'est compliqué." ou "Non, je ne peux pas vraiment l'expliquer." ou "Ne vous en faites pas." Plus le personnel est expérimenté pour l'examen du projet, moins il a de chances de laisser «c'est juste des trucs que je ne peux pas bien expliquer» voler. Mieux si vous pouvez approfondir au moins un niveau pour que les autres se sentent à l'aise que 1) vous sachiez ce que vous '

Alors, ayez un croquis de MVC dans votre poche de hanche, prêt à partir. Quelque chose comme:

"C'est un peu technique, mais ... MVC divise le code en modèles (responsables des données de base et de la logique métier), vues (qui affiche les données) et contrôleurs (qui gèrent les interactions et les mises à jour des utilisateurs). C'est une architecture éprouvée- «le modèle de conception le plus réussi de l'ingénierie logicielle». Je sais que cela pourrait ressembler à «juste de la plomberie», mais pour gérer toutes les demandes qui arrivent, nous avons besoin d'une base plus solide. Cela nous mettra sur la bonne base pour construire de nouvelles fonctionnalités et résoudre les bogues plus rapidement. "

Même s'ils ne comprennent pas complètement MVC à la fin de celui-ci, et même si vous avez dû trop simplifier pour le rendre compréhensible ("casser des œufs pour faire une omelette"), je parie que vous le trouverez beaucoup plus confortable pour avoir une explication prête que d'avoir à dire «je ne peux pas l'expliquer» ou «vous n'êtes pas qualifié pour la comprendre» aux cadres supérieurs.

afin d'améliorer la flexibilité des modifications apportées au logiciel

Les managers sont intéressés par le résultat final. Moins ils sont techniques, moins ils sont concernés par la façon dont vous y arrivez. MVC est très courant, populaire et éprouvé.

Lorsque des demandes de modification sont faites à l'avenir, vous pouvez informer la direction qu'elles peuvent être rendues plus faciles et plus rapides. Tout le monde aime entendre ça.

C'est une stratégie courante, donc l'embauche de nouveaux développeurs ne devrait pas poser de problème. En fait, vous pourriez attirer de meilleurs développeurs qui sont de fervents partisans.

Tout cela sera très difficile s'il y a beaucoup de problèmes urgents dans ce projet particulier. Ils peuvent ne pas vouloir faire un pas en arrière, vous pouvez donc faire deux pas en avant. La solution peut être d'attendre ou de mettre en œuvre en petits morceaux.

• Modèle - Fils / électricité
• Vue - Luminaire
• Contrôleur - interrupteur d'éclairage

Relation facile des composants (luminaire, interrupteur / variateur de lumière). Peut-être pas tellement le câblage, mais cela peut encore être fait sans affecter d'autres composants. Tout le monde devrait pouvoir visualiser cela dans sa tête, même les types de marketing / vente. (Séparation claire, etc.)

Dites maintenant à votre patron / collègues que dans notre application / système, le commutateur est intégré à l'intérieur du luminaire et le luminaire est enroulé autour de fil de cuivre. Imaginez maintenant essayer de mettre à jour le luminaire, l'interrupteur ou le fil. Très coûteux, impact sur les autres composants très élevé et peut-être dangereux à faire sans casser autre chose.

MVC applique un modèle à la base de code qui transforme le désordre (mais qui fonctionne) en quelque chose où les changements peuvent se produire plus rapidement et plus facilement avec moins d'erreurs.

Un moyen facile de comprendre MVC: le modèle est les données , la vue est la fenêtre sur l'écran et le contrôleur est la colle entre les deux .

La meilleure rubrique de tous les temps: "Nous avons besoin de modèles SMART, de contrôleurs minces et de vues DUMB"

Comme pour les autres modèles de conception de logiciels, MVC exprime le « cœur de la solution » à un problème tout en permettant son adaptation à chaque système. Il est préférable de le voir comme un concept plutôt que comme une implémentation spécifique. Il existe de nombreuses implémentations du concept.

Toutes les variantes MVC utilisent la même division de composants, mais généralement, elles diffèrent dans la façon dont ces composants interagissent.

Pour ceux d'entre vous qui ne le savent pas, MVC a été initialement décrit en termes de modèle de conception à utiliser avec Smalltalk par Trygve Reenskaug en 1979 . Son article a été publié sous le titre "Programmation d'applications dans Smalltalk-80: Comment utiliser Model-View-Controller", et a préparé le terrain pour la plupart des futures implémentations MVC.

Je suis à moitié d'accord avec Oded - apprendre à convaincre vos pairs et gestionnaires non techniques que ce que vous faites est important et utile, sans expliquer les détails, est une compétence nécessaire que vous seriez sage de développer.

Cependant, je pense qu'avoir la capacité d'expliquer des concepts complexes en termes simples aide réellement à cela - un problème que les gestionnaires non techniques ont souvent est que, comme ils ont du mal à comprendre exactement ce que font les techniciens, ils ont tendance à méfiez-vous d'eux. C'est juste la nature humaine: il est plus facile de croire que quelque chose que vous ne comprenez pas est inutile ou faux que d'y mettre votre foi. Par conséquent, si vous pouvez rendre les concepts faciles à comprendre à volonté, vous pouvez les utiliser chaque fois que vous en avez besoin, et au fil du temps, vos responsables non techniques apprendront qu'ils peuvent les comprendre s'ils le souhaitent - vous n'en tirez pas un sur eux - vous leur épargnez juste les détails pour leur propre raison. Ils vous feront plus confiance.

Cela mis à part, répondons à la question:

Je trouve utile d'utiliser des analogies que les gens d'affaires comprennent. Pour MVC, je le décris comme une entreprise.

• Les modèles sont responsables de la logique métier et des données - ce sont les éléments qui définissent ce que fait le programme et les détails de la façon dont il le fait. Si le programme était une entreprise, les modèles seraient les entrepôts, les usines, les travailleurs et les biens d'équipement. Ce sont également les gestionnaires de niveau inférieur qui s'assurent que les règles sont respectées et que la politique est appliquée.
• Les vues sont la couche de présentation - elles montrent aux utilisateurs ce qui se passe dans le système et fournissent un moyen d'interagir avec le programme. Si notre programme était une entreprise, les vues seraient comme le plancher de la salle d'exposition, le stand de vente à la convention commerciale ou les représentants des ventes. Ils affichent des options, fournissent des informations et des commentaires conviviaux et reprennent les demandes à l'entreprise.
• Les contrôleurs sont la couche de coordination - ils s'assurent que les informations passent des modèles aux vues et vice versa, et que tout fonctionne ensemble pour faire leur travail. Si le programme était une entreprise, les contrôleurs seraient les cadres moyens et supérieurs. Ils ne s'impliquent pas trop dans les détails, mais ils s'assurent que les bonnes personnes ont les bons outils pour faire leur travail, et ils approuvent ou refusent les décisions de haut niveau. Ils fournissent la direction générale pour que les choses puissent fonctionner ensemble.

L'avantage de l'expliquer avec cette analogie est qu'un bon gestionnaire verra la sagesse de séparer les préoccupations de cette façon, et pourrait décider qu'elles devraient être plus proches du contrôleur, et ne pas trop s'impliquer dans les détails à l'avenir!

J'espère que cela répondra au "quoi" - le "pourquoi" est également facile avec cette analogie:

Imaginez une entreprise idéale, où chaque département est responsable d'un ensemble de tâches et sait qu'il aura toujours les ressources dont il a besoin sans avoir à se soucier de ce que font les autres. Un commercial trouve un client, récupère sa commande, la transmet à la direction qui l'approuve, puis elle se rend à l'entrepôt / production / ingénierie pour exécution. La rétroaction est directe - personne d'autre n'a besoin de s'impliquer, sauf en cas de problème. C'est une bonne conception MVC - chaque pièce a un travail, et elle n'a pas à se soucier des autres pièces. De cette façon, il est facile de changer si nous en avons besoin. Dans une conception non MVC, les responsabilités ne sont pas claires. Le représentant commercial peut essayer de modifier le produit lorsque le client demande quelque chose de différent. Ou ils peuvent donner des prix différents selon ce qu'ils ont ressenti ce jour-là. Le PDG pourrait être en train de jouer avec la chaîne de production, alors qu'il devrait se demander comment mettre en place une chaîne d'approvisionnement plus fiable. Les employés de l'entrepôt pourraient être sur le terrain de vente pour parler aux clients quand ils devraient exécuter les commandes déjà prises.

En d'autres termes, une bonne conception MVC permet à chaque pièce de se concentrer sur une chose, afin qu'elle puisse le faire correctement - tout comme une entreprise bien organisée.

** Avis de non-responsabilité - si votre entreprise est mal organisée, elle pourrait s'en offusquer. Dans ce cas, vous aurez besoin d'une autre analogie. Vous pourriez également avoir besoin d'un travail différent.

Les avantages de MVC résident principalement dans la séparation des préoccupations:

Cela permet aux gens de se concentrer sur ce qu'ils font le mieux.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

Cela réduit les coûts car les systèmes entrelacés nécessitent que le personnel soit soit des experts dans tous ces domaines, soit vous êtes plus susceptible d'avoir des problèmes lorsqu'un changement dans un domaine affecte les autres.

Fournissez des exemples réels d'architectures MVC: téléphones cellulaires, téléphones de bureau, Skype, etc. La modification de la vue (type de pavé numérique, haut-parleurs, micros) n'affecte pas le modèle (le signal audio), le contrôleur est le circuit le téléphone qui traduit les ondes sonores en signaux audio.

Je leur dirais que MVC sépare mes préoccupations.

Ma première préoccupation est la logique du code - ce que je fais en coulisses pour que le site Web exécute les actions qu'il souhaite.

Ma deuxième préoccupation est la logique métier - ce qu'ils (l'utilisateur) veulent que l'application fasse.

Ma troisième préoccupation est à quoi ressemble le site - La page qu'ils visitent pour faire ce qu'ils veulent.

(Je ne leur dirais pas cette partie suivante) Donc, dans l'ordre, mes explications étaient pour le modèle, le contrôleur et la vue.

Expliquez les avantages

J'expliquerais MVC en termes d'avantages commerciaux. Vos managers seront en mesure de comprendre cela et se rallieront si les avantages sont convaincants.

MVC vous permet de décomposer votre application en unités sensibles, dont chacune existe indépendamment des autres. Vous obtenez un code propre, maintenable, testable et potentiellement une réutilisation de code entre les systèmes.

Le modèle

Chaque modèle encapsule un seul type d'informations commerciales, par exemple, un enregistrement client ou un produit, ainsi que toute la logique métier associée.

Cette séparation vous permet de tester facilement votre logique métier indépendamment des autres parties de votre application.

Vous pouvez également facilement étendre l'application en ajoutant des modèles supplémentaires, c'est très modulaire et propre.

Chaque modèle en théorie peut exister indépendamment des autres. Vous pouvez envisager d'appliquer cela en utilisant des objets de service pour gérer les relations entre les modèles. Vous pouvez échanger des modèles sans affecter le reste du système.

La vue

Séparer votre vue vous permet de mettre à jour facilement votre frontal sans casser le backend sous-jacent.

Vous pouvez donner votre code frontal à un autre développeur sans nécessairement lui donner accès à l'ensemble du système.

Vous êtes également libre de créer des frontaux alternatifs qui fonctionnent avec le système existant. Vous pouvez afficher vos données sous forme d'application mobile, d'API, de PDF ou de feuille de calcul Excel. Vous pouvez le faire sans pirater le reste du système. Vous êtes moins susceptible de casser des choses accidentellement. Vous pouvez facilement créer des points d'intégration auxquels les systèmes existants peuvent se connecter.

Le controlle

Le contrôleur connecte les modèles à la vue. Il garde tout séparé. Vous pouvez câbler dans une vue différente très facilement. Si vous modifiez le code de votre modèle, la vue n'a même pas besoin de le savoir.

Autres avantages

C'est un modèle courant. D'autres développeurs pourront comprendre votre code et travailler dessus. Si vous revenez à votre code des années plus tard, vous pourrez probablement le comprendre et apporter des modifications. Votre code sera moins susceptible de devenir un autre casse-tête hérité pour un futur développeur.

Parce que tout a sa place, il est beaucoup plus facile de produire du code propre. Le risque de spaghettification est considérablement réduit (mais pas éliminé). Votre code devient maintenable.

Parce que tout est modulaire, vous pouvez en tester certaines parties isolément. Votre code est testable et moins susceptible de contenir des bogues ou des failles de sécurité. Les futures mises à niveau seront beaucoup plus faciles car vous pourrez tester facilement l'ensemble du système.