Déplacer toute la logique de l'interface utilisateur vers le côté client?

9

Notre équipe était initialement composée principalement de développeurs côté serveur avec une expertise minimale en Javascript. Dans ASP.NET, nous écrivions beaucoup de logique d'interface utilisateur en code-behind ou plus récemment via des contrôleurs dans MVC.

Il y a quelque temps, 2 développeurs de haut niveau côté client ont rejoint notre équipe. Ils peuvent faire en HTMl / CSS / Javascript à peu près tout ce que nous pouvions faire auparavant avec du code côté serveur et des contrôles Web côté serveur:

  • Afficher / masquer les commandes
  • Faire la validation
  • Contrôle rafraîchissant AJAX

J'ai donc commencé à penser qu'il serait peut-être plus efficace de simplement créer une API de haut niveau autour de notre logique métier, un peu comme l'API Amazon Fulfillment: http://docs.amazonwebservices.com/fws/latest/APIReference/ , pour que le client les développeurs côté reprendraient entièrement l'interface utilisateur, tandis que les développeurs côté serveur se concentreraient uniquement sur la logique métier.

Donc, pour commander le système, vous auriez une API de haut niveau comme:

OrderService.asmx

CreateOrderResponse CreateOrder(CreateOrderRequest)
AddOrderItem
AddPayment
-
SubmitPayment
-
GetOrderByID
FindOrdersByCriteria
...

Il y aurait un accès JSON / REST à l'API, il serait donc facile de consommer à partir de l'interface utilisateur côté client. Nous pourrions utiliser cette API à la fois pour le développement de l'interface utilisateur interne et également pour les tiers pour créer leurs propres applications.

Avec les progrès de Javascript et la disponibilité de bons développeurs côté client, est-ce le bon moment pour se débarrasser du code-behind / contrôleurs et se concentrer uniquement sur le développement d'API de haut niveau (ala Amazon) que les développeurs côté client peuvent consommer?

javascript architecture asp.net team enterprise-architecture Mag20
la source

Réponses:

6

La validation côté client pour décharger le côté serveur et augmenter la réactivité de l'application est correcte, mais faites toujours la validation côté serveur. On peut désactiver JavaScript et lorsque vous utilisez directement l'API REST, aucun JavaScript ne sera jamais nécessaire.

Htbaa
la source
Oui, la validation ferait également partie du domaine / API. Le côté client tirerait ce qui doit être validé de l'API ou nous documenterions ce qui est requis, etc ... pour chaque méthode. S'il y a encore des erreurs de validation sur les soumissions du côté client - nous lèverions des exceptions.
Mag20
4

Une chose à savoir est que les interfaces utilisateur complexes peuvent nécessiter une couche supplémentaire "Aide à l'interface utilisateur" pour prendre en charge des éléments tels que les hiérarchies, les relations maître / détail et d'autres concepts d'interface utilisateur qui n'existent pas vraiment dans la couche métier. Il n'est souvent pas possible d'implémenter certaines de ces capacités sans effectuer plusieurs allers-retours vers la couche métier, ce qui dégrade les performances. Au moins, je préfère avoir la couche "UI assist" plutôt que de donner à l'interface un accès direct à la base de données.

TMN
la source