Architektura oparta na JSON, jak najlepiej zsynchronizować front end i back-end

Question

Patrząc na użycie JSON-a do nowego systemu opartego na REST opartego na REST i wygląda świetnie, ale jest jedna rzecz, która nawiązuje do mojego zrozumienia. Jaka jest strategia synchronizacji JSON po obu stronach aplikacji?

Co mam na myśli przez to, jeśli robisz GET dla: www.mysite.com/item/12345. Następnie strona .net aplikacji przechodzi do bazy danych, pobiera element o identyfikatorze 12345 i rozpatruje go w modelu obiektowym Obiekt, który jest następnie serializowany do JSON i zwracany.

Jeśli zrobić pocztą na adres: www.mysite.com/item i pass -

{ 
    "Id": "12346", 
    "ItemName": "New Item", 
    "ItemCost": 45 
} 

Następnie strona .net aplikacji podnosi go, deserializuje go do obiektu element, a następnie oddaje go do dodania do bazy danych.

W jaki sposób uzyskać synchronizację obu stron, modelu obiektu JS i serializacji modelu obiektów .net? Czy to musi być utrzymywane ręcznie lub czy istnieje sprytny sposób dostarczenia szablonu dla JSON w oparciu o serializację modelu .net?

Po prostu szukam najlepszych praktyk i co zrobiłem, i nie widzę, jak strona klienta wie, co JSON przekazać stronie serwera.

Answer 1

Osobiście uważam, że łatwiej jest "prowadzić" te zmiany w środowisku .NET. Nie chcąc nauczyć cię ssania jaj, ale Javascript jest językiem bardzo luźno związanym, co oznacza, że ​​zmiany/funkcjonalność/właściwości mogą być dodawane do kopyta, podczas gdy w .NET znacznie łatwiej jest testować i stabilizować twoje POCO w bardziej sztywny sposób.

Jedną z metod, z którymi ostatnio się bawiłem, jest generowanie pustych POCO z mojej usługi podczas tworzenia obiektów, odpowiednie manipulowanie nimi, a następnie ponowne wysyłanie ich do usługi w celu zachowania trwałości itp. Nie rozwiązuje to jednak uczucia w stylu dzikiego zachodu pracy w Javascript, ale przynajmniej Kontrakty Danych mogą się równać z powierzchownym poziomem.