Pourquoi utiliser MVC?

Bonjour,

Tout est dans le titre. J'aimerais savoir pourquoi de plus en plus de gens développement veulent à tout pris employer l'architecture MVC? Partout où il y a des annonces d'emplois les recruteurs veulent à tout pris que leur candidat connaisse MVC.

Pourquoi utiliser MVC plutôt qu'autre chose? Pourquoi ne pas développer sa propre architecture? Pourquoi existe-il si peu d'architectures?

Ça me frappe de voir à quel point il y a de projets qui emploient cette architecture.

Personnellement je ne l'ai quasiment jamais utilisé et pourtant mes sites web vont de bon train! Serait-ce parce qu'elle est très simple, rapide à comprendre, mettre en place et gérer?

Salut,

Citation:

---

J'aimerais savoir pourquoi de plus en plus de gens développement veulent à tout pris employer l'architecture MVC? Partout où il y a des annonces d'emplois les recruteurs veulent à tout pris que leur candidat connaisse MVC.

---

MVC est une architecture applicative: elle définit un canevas dans lequel pourront être placés les différents composants applicatifs en fonction de leur nature et ce indépendamment de ce que fera la réalisation.

C'est une architecture qui 'parle' pour répartir les différentes fonctions dans un tel environnement et préfigurer les compétences à avoir pour les réaliser.

Plus pratiquement...
Donner à M la réalisation de la fonction X du Modèle suppose que M sache un peu lire la prose métier et ce qu'est une base de donnée.
Donner à N la réalisation de la View, suppose que N connaît CSS, XML, JSON et autres HTMLerie,...

Maintenant, pour faire votre projet, dire MVC ne permettra pas à lui seul de trouver vos maçons: Java / .Net / PHP / ??? seront sans doutes aussi utiles sinon plus.

Une architecture comparable est PAC: Presentation-Abstraction-Control.

Citation:

---

Pourquoi utiliser MVC plutôt qu'autre chose? Pourquoi ne pas développer sa propre architecture? Pourquoi existe-il si peu d'architectures

---

Une architecture est une sorte d'organisation qui permet de répartir des fonctions sur un ensemble de ressources (et/ou d'organiser le boulot pour construire la chose correspondante).

Si les possibilités de répartition +/- optimales des fonctions sur les ressources sont limités, le nombre d'architectures le sera aussi.

Ce qui ne signifie pas une grande variabilité.
A la base d'une application multi-utilisateurs, vous avez des IHM et une/des
fonctions de persistance (base de donnée).

Si l'IHM est un client lourd, à chaque mise à jour il faudra aller sur tous les postes clients... Si vous avez 1000 utilisateurs, vous ne le ferez pas deux fois: donc navigateur et on descend la logique dans un serveur d'application.

Mais entre les deux, ce seront deux implémentations différentes d'une architecture MVC construites avec des technos différentes et des personnes différentes.

Ajoutons de la persistance (cache) et des actions dans le client (javascript et ajax), et voilà que vous avez un peu de MVC dans le seul navigateur et qu'il serait sage de rebaptiser cela d'un autre nom...

Microsoft a essayé avec MVVM mais en fait, tout le monde s'en fout car... les technologies ne sont pas encore assez "mûres" pour tracer des frontières 'stables' qui aient une valeur ajoutée dans l'organisation de la solution ou du travail correspondant.

Note: Dans la pratique, vous vous alignez prudemment derrière l'architecture proposée par le constructeur - qui appellera çà comme il veut - leurs produits étant fortement structurés par celle-ci, il faudra vivre avec.

En espérant vous avoir un peu éclairé
- W