Поддержание согласованности между объектными моделями JavaScript и C # - PullRequest
Новая
       34

Поддержание согласованности между объектными моделями JavaScript и C #

5 голосов
/ 22 января 2010

Я работаю над веб-приложением ASP.NET, которое использует много JavaScript на стороне клиента, чтобы позволить пользователю выполнять такие действия, как переупорядочение списков с помощью перетаскивания, поиск элементов для добавления в список (например, предложения в строке поиска Google), удаление элементов из списка и т. д.

У меня есть JavaScript-класс, который я использую для хранения каждого элемента списка на стороне клиента, а также информацию о том, какое действие пользователь выполнил над элементом (добавление, редактирование, удаление, перемещение). Единственный раз, когда страница публикуется на сервере, это когда пользователь готов, перед тем, как страница отправлена, я сериализирую всю информацию об изменениях, внесенных в JSON, и сохраняю ее в скрытых полях на странице.

Что я ищу, так это несколько общих советов о том, как создавать мои классы в C #. Я думаю, что было бы неплохо иметь класс в C #, который совпадает с классом JavaScript, так что я могу просто десереализовать JSON для экземпляров этого класса. Хотя немного странно иметь классы на стороне сервера, которые напрямую дублируют классы JavaScript и существуют только для поддержки реализации пользовательского интерфейса JavaScript.

Это своего рода абстрактный вопрос. Я просто ищу руководство от тех, кто проделал аналогичные вещи с точки зрения поддержки соответствия объектных моделей на стороне клиента и сервера.

1 Ответ

1 голос
/ 22 января 2010

Имеет смысл. Если бы я столкнулся с этой проблемой, я бы подумал об использовании единого окончательного описания типа данных или класса, а затем о создании кода из этого описания.

Описание может быть исходным файлом javascript; Вы можете создать парсер, который генерирует соответствующий код C # из этого JS. Или это может быть исходный файл C #, и вы делаете обратное.

Вы можете найти больше полезности в описании этого в RelaxNG, а затем в создании (или поиске) генератора для C # и Javascript. В этом случае схема RelaxNG будет проверена в управлении исходным кодом, а сгенерированные артефакты - нет.

EDIT : Также есть зарождающаяся спецификация под названием WADL , которая, я думаю, также поможет в этом отношении. Я не оценивал WADL. Периферически, я знаю, что это не захватило мир штормом, но я не знаю, почему это так. Есть вопрос по SO относительно этого .

РЕДАКТИРОВАТЬ 2: Учитывая отсутствие инструментов (WADL, очевидно, мертворожденный), на вашем месте, я мог бы попробовать этот тактический подход:

  • Используйте атрибуты [DataContract] в ваших типах c # и рассматривайте их как окончательные.
  • создайте инструмент, который выкидывает ваш тип C # из скомпилированной сборки и создает экземпляр этого типа с помощью JsonSerializer в образце XML-документа JSON, который обеспечивает своего рода де-факто «определение объектной модели». Инструмент должен каким-то образом проверить, что созданный экземпляр типа может возвращаться в эквивалентный JSON, возможно, с контрольной суммой или CRC в полученном материале.
  • запустить этот инструмент как часть процесса сборки.

Чтобы это произошло, вам нужно включить этот «образец JSON-документа» в исходный код, а также убедиться, что , что - это форма, которую вы использовали в различных JS. код в вашем приложении. Поскольку Javascript является динамическим, вам также может понадобиться верификатор типа или что-то еще, что будет выполняться как часть jslint или какого-либо другого шага проверки во время сборки, который проверит ваш источник Javascript, чтобы увидеть, что он использует ваши «стандартные» определения модели объекта. ,

...