Utrzymywanie spójności między JavaScriptem a modelami obiektów w języku C#

Question

Pracuję nad aplikacją sieci Web ASP.NET, która używa dużej liczby skryptów JavaScript po stronie klienta, aby umożliwić użytkownikowi np. Zmianę kolejności list metodą przeciągania i upuszczania, wyszukiwanie elementów do dodania do listy (np. sugestie w pasku wyszukiwania Google), usuwania pozycji z listy itp.

Mam "klasę" JavaScript, której używam do przechowywania każdego elementu listy po stronie klienta jako oraz informacje o tym, jakie działanie wykonał użytkownik na przedmiocie (dodawanie, edycja, usuwanie, przenoszenie). Jedyny moment, w którym strona zostanie opublikowana na serwerze, to fakt, że użytkownik, tuż przed przesłaniem strony, szereguje wszystkie informacje o zmianach wprowadzonych w JSON i zapisuje je w ukrytych polach na stronie.

To, czego szukam, to ogólne porady dotyczące tego, jak budować moje zajęcia w języku C#. Myślę, że może być miło mieć klasę w języku C#, która pasuje do kodu JavaScript, więc mogę po prostu zreformować JSON na instancje tej klasy. Wydaje się jednak nieco dziwne, że mamy klasy po stronie serwera, które bezpośrednio powielają klasy JavaScript i istnieją tylko w celu obsługi implementacji interfejsu JavaScript.

To jest pytanie abstrakcyjne. Po prostu szukam wskazówek od innych, którzy zrobili podobne rzeczy w zakresie utrzymywania pasujących modeli obiektów po stronie klienta i serwera.

Answer 1

Ma doskonały rozsądek. Gdybym skonfrontował się z tym problemem, rozważałbym użycie pojedynczego ostatecznego opisu typu danych lub klasy, a następnie wygenerowanie kodu z tego opisu.

Opis może być plikiem źródłowym javascript; możesz zbudować parser, który wygeneruje odpowiedni kod C# z tego JS. Lub może to być plik źródłowy C# i wykonujesz konwersację.

Możesz znaleźć więcej użyteczności w opisywaniu go w RelaxNG, a następnie budować (lub znajdować) generator zarówno dla C#, jak i Javascript. W takim przypadku schemat RelaxNG zostanie sprawdzony pod kontrolą kodu źródłowego, a wygenerowane artefakty nie.

---

EDIT: Nie ma też rodząca Spec nazywa WADL, który myślę, że pomóc w tym zakresie, jak również. Nie oceniłem WADL. Pośrednio zdaję sobie sprawę, że nie przejął on świata przez burzę, ale nie wiem, dlaczego tak się dzieje. There's a question on SO regarding that.

---

EDIT2: względu na brak narzędzi (WADL widocznie Stillborn), gdybym Cię mogę spróbować tego taktycznego podejścia:

• użyć atrybutów [DataContract] na swoim C# typów i leczyć te jako ostateczne.
• zbudować narzędzie, które slurps w typ C#, ze skompilowanego zespołu i tworzenia instancji typu, przy użyciu JsonSerializer na przykładowy dokument XML JSON, który zapewnia, rodzaj defacto "definicji modelu obiektowego". Narzędzie powinno w jakiś sposób zweryfikować, czy instancjonowany typ może w obie strony przejść do równoważnego JSON, może z sumą kontrolną lub CRC na wynikowym fakcie.
• uruchom to narzędzie jako część procesu kompilacji.

Aby tak się stało, trzeba by sprawdzić, że „próbki dokumentów JSON” do kodu źródłowego i chcesz także mieć pewność, żejest forma uzywasz w różnych kodu JS w Twojej aplikacji. Ponieważ JavaScript jest dynamiczny, może być również potrzebny weryfikator typów lub coś, co działałoby jako część jslint lub innego kroku weryfikacji w czasie instalacji, który sprawdziłby twoje źródło JavaScript, aby zobaczyć, że używa on "standardowych" definicji modelu objbect. .