Le maintien de la cohérence entre JavaScript et C# Modèles d'objet

Question

Je travaille sur une application Web ASP.NET qui utilise beaucoup de JavaScript côté client pour permettre à l'utilisateur de faire des choses comme réordonnancement glisser-déposer des listes, à la recherche des objets Pour ajouter à la liste (comme les suggestions dans la barre de recherche Google), supprimer des éléments de la liste, etc.

J'ai une «classe» JavaScript que j'utilise pour stocker chacun des éléments de la liste du côté client ainsi que des informations sur l'action de l'utilisateur sur l'élément (ajouter, modifier, supprimer, déplacer). La seule fois où la page est publiée sur le serveur, c'est quand l'utilisateur a terminé, juste avant que la page ne soit soumise. Je sérialise toutes les informations sur les changements qui ont été faits dans JSON et les stocke dans des champs cachés sur la page.

Ce que je cherche quelques conseils généraux sur la façon de construire mes classes en C#. Je pense qu'il pourrait être sympa d'avoir une classe en C# qui corresponde à celle de JavaScript, donc je peux juste désérialiser le JSON aux instances de cette classe. Il semble cependant un peu étrange d'avoir des classes côté serveur qui à la fois dupliquent directement les classes JavaScript et n'existent que pour prendre en charge l'implémentation de l'interface utilisateur JavaScript.

Ce genre est d'une question abstraite. Je suis à la recherche de conseils de la part d'autres personnes qui ont fait des choses similaires en termes de maintenance des modèles d'objets latéraux client et serveur correspondants.

Answer 1

Fait parfaitement sens. Si je devais faire face à ce problème, je envisagerais d'utiliser une seule description définitive du type ou de la classe de données, puis de générer du code à partir de cette description.

La description peut être un fichier source javascript; vous pourriez construire un analyseur qui génère le code C# approprié à partir de ce JS. Ou, ce pourrait être un fichier source C#, et vous faites l'inverse.

Vous trouverez peut-être plus d'utilité pour décrire dans RelaxNG, et puis la construction (ou découverte) un générateur pour C# et Javascript. Dans ce cas, le schéma RelaxNG serait vérifié dans le contrôle de code source, et les artefacts générés ne le seraient pas.

---

EDIT: Il y a aussi une spécification naissante appelée WADL, qui je pense serait utile à cet égard également. Je n'ai pas évalué WADL. En périphérie, je suis conscient qu'il n'a pas pris le monde d'assaut, mais je ne sais pas pourquoi c'est le cas. There's a question on SO regarding that.

---

EDIT2: Compte tenu du manque d'outils (WADL est apparemment mort-né), si je vous je pourrais essayer cette approche tactique:

• Utilisez les [DataContract] attributs de vos c types # et traiter ceux qui sont définitifs.
• construire un outil qui slurps dans votre C# type d'un assemblage compilé et instancier le type, en utilisant le JsonSerializer sur un XML exemple de document JSON, qui fournit une sorte de defacto « Définition du modèle d'objet ». L'outil devrait en quelque sorte vérifier que le type instancié peut aller-retour en JSON équivalent, peut-être avec une somme de contrôle ou un CRC sur les choses qui en résultent. Exécutez cet outil dans le cadre de votre processus de génération.

Pour ce faire, il vous faudrait vérifier dans ce « échantillon document JSON » dans le code source et vous auriez également vous assurer que est la forme que vous utilisez dans les différents codes JS dans votre application Puisque Javascript est dynamique, vous pourriez aussi avoir besoin d'un vérificateur de type ou quelque chose, qui ferait partie de jslint ou d'une autre étape de vérification de la compilation, qui vérifierait votre source Javascript pour voir qu'elle utilise vos définitions de modèle d'objbect standard. .