web-dev-qa-db-fra.com

client-MVC vs serveur-MVC

Je souhaite obtenir l'avis d'autres utilisateurs sur les avantages de MVC côté serveur. Avec la puissance de nombreuses bibliothèques javascript. A quoi bon le serveur MVC côté serveur?

Vous pouvez facilement utiliser MVC côté client avec des modèles et une API REST pour créer une application beaucoup plus réactive avec moins de temps système pour recharger une page entière en cas de modifications mineures.

model-view-controllerclient-sideserver-side
21
Justin

Avantages du serveur MVC:

  1. Mature.
  2. Largement adoptée.
  3. La plupart du code est à l'intérieur du serveur, il devrait donc être plus sécurisé.

Mais il est clair que la tendance est de revenir à l’informatique client/serveur mais aux gros clients écrits en C ou dans une autre langue, mais vous disposez maintenant d’une plate-forme très agréable: le navigateur.

J'ai une politique simple concernant l'utilisation de MVC côté serveur et de MVC côté client:

  1. Utilisateurs occasionnels avec peu d'interactions: Server + Ajax.
  2. Application métier (comptabilité, ERP, CRM, etc.): client.

BTW j'utilise Java Server Faces pour # 1 et ExtJS sauvegardé par les services JAX-RS pour # 2.

Cordialement.

5
ssamayoa

À mon avis, le MVC côté serveur reste pertinent si vous considérez le V comme votre MVC côté client, enveloppé dans une boîte noire. Le fait est que tout est une question de collaboration et d’évolutivité. Le serveur MVC côté serveur continue d'alimenter les API REST (par exemple) en partant du principe que vous externalisez techniquement la technologie d'affichage dans un cadre distinct s'exécutant dans votre navigateur.

Le navigateur étant de plus en plus considéré comme une plate-forme de développement d'applications, vous pouvez exporter d'énormes quantités de données de votre "plate-forme backend" vers le client (navigateur), puis les traiter comme une "base de données" locale dans votre navigateur, ce qui permet un temps de réponse rapide.

La combinaison de ces 2 frameworks MVC permet:

  1. Trafic insuffisant entre le serveur et le client, réduisant ainsi la latence
  2. Augmenter la réactivité de vos applications Web en localisant l'accès à un ensemble de données plus pertinent
  3. Répartir la charge d'un seul contrôleur côté serveur vers des centaines de navigateurs

L'architecture à l'œuvre ici est très similaire aux CDN - réseaux de diffusion de contenu! En réalité, il s’agit de localiser des données et de les rapprocher des centres de traitement.

Cela dit, vous pouvez continuer à utiliser l'un de ces éléments au détriment des autres, si vous comprenez les besoins architecturaux de votre produit. Bon outil pour le bon travail.

11
Kingz

Eh bien, vous aurez toujours besoin d'une page initiale, qui pourrait être servie par un moteur MVC côté serveur.

En dehors de cela, client-MVC + REST pourrait fonctionner, mais je pense que dans les grandes applications, vous avez toujours différentes sections et vous devez les lier ensemble. Ce serait possible de le faire côté client, mais je pense qu'il est plus facile de le faire côté serveur.

Pour le moment, je peux voir les deux coexister avec bonheur. Vous pouvez toujours faire autant que possible du côté client et via REST, mais si quelque chose n'est pas possible côté client, vous bénéficiez toujours des avantages de MVC côté serveur.

6
Kenneth

Comparer just / MVC d'un point de terminaison à l'autre n'est pas très constructif. MVC est la structure de votre organisation du code. C'est une famille de modèles de conception qui vous permet de découpler votre code et de le rendre plus facile à gérer. Nous voulons que toujours.

Tout le monde conviendra que, que vous construisiez sur le serveur ou sur le client, vous devez disposer d'une bonne architecture avec une séparation des préoccupations. Il n'y a pas de concours là-bas.

La vraie et la plus importante question est la suivante: Rendu côté client vs côté serveur? Où souhaitez-vous générer vos vues HTML, sur le serveur ou le client? C'est une question différente qui est plus préoccupée par la vitesse de la page et la réactivité de l'interface utilisateur. En outre, il a été répondu plusieurs fois à plusieurs endroits. Recherche ex: https://stackoverflow.com/search?q=client+rendering+vs+server+rendering

3
givanse

Je pense que MVC est un excellent modèle pour les applications Web simples. Cependant, cela n’aide pas vraiment lors de la création d’applications Web riches et modernes telles que Facebook ou Gmail. Jetez un coup d'œil à cet article pour plus de raisons, pourquoi ne pas utiliser MVC:

http://dennis-nerush.blogspot.co.il/2016/04/should-we-use-mvc-for-modern-web.html

0
Dennis Nerush