ASP.NET MVC 2 AJAX дилемма: концепция Lose Models или создание неуправляемого JavaScript

Question

Хорошо, давайте предположим, что мы работаем с ASP.NET MVC 2 (последний и самый лучший предварительный просмотр) и хотим создать пользовательский интерфейс AJAX с помощью jQuery. Каковы наши реальные варианты здесь?

Опция 1 - передать Json из контроллера в представление, а затем представление отправит Json обратно в контроллер. Это означает (в указанном порядке):

1. Пользователь открывает некоторое представление (скажем, - / Invoices / January ), которое должно визуализировать список данных (например, <IEnumerable<X.Y.Z.Models.Invoice>>)
2. Контроллер извлекает модель из хранилища (при условии, что мы используем шаблон хранилища).
3. Контроллер создает новый экземпляр класса, который мы будем сериализовать в Json. Причина, по которой мы это делаем, заключается в том, что модель не может быть сериализуемой (циклическая ссылка ftl )
4. Контроллер заполняет класс, который скоро будет сериализован, данными
5. Контроллер сериализует класс Json и передает его в представление.
6. Пользователь вносит некоторые изменения и отправляет «форму»
7. Представление отправляет обратно Json контроллеру
8. Контроллер теперь должен «вручную» проверять ввод, поскольку переданный Json не привязывается к модели

Посмотрите, если наш View взаимодействует с контроллером через Json, мы теряем проверку модели, что, по моему мнению, является невероятным недостатком. В этом случае забудьте о аннотациях данных и прочем.

Вариант 2 - Хорошо, альтернатива первого подхода - передать Модели в Представления, что является поведением по умолчанию в шаблоне при запуске нового проекта.

1. Передаем строго типизированную модель на просмотр
2. Представление отображает соответствующий html и javascript, придерживаясь имен свойств модели. Это важно!
3. Пользователь отправляет форму. Если мы придерживаемся названий моделей, когда мы .serialize() заполняем форму и отправляем ее в контроллер, она сопоставляется с моделью.
4. Нет карт Json. Представленная форма напрямую привязана к строго типизированной модели, следовательно, мы можем использовать проверку модели. Например. мы сохраняем бизнес-логику там, где она должна быть.

Проблема с этим подходом заключается в том, что если мы проведем рефакторинг некоторых Моделей (изменим имена свойств, типы и т. Д.), Написанный нами javascript станет недействительным. Нам придется вручную рефакторинг скриптов и надеяться, что мы что-то не упустим. Вы также не сможете проверить это.

Хорошо, вопрос в том, как написать внешний интерфейс AJAX, который поддерживает проверку бизнес-логики в модели (например, контроллер передает и получает тип модели), но в то же время не портит JavaScript и HTML, когда мы проведем рефакторинг модели?

Answer 1

Проблема с этим подходом, если мы Реорганизовать некоторые из моделей (изменить имена свойств, типы и т. д.), JavaScript, который мы написали, стал бы недействительный.

Я не вижу, как изменение свойства модели меняет javascript-код. Обычно вы захватываете событие отправки формы и отправляете его через ajax. Нет прав собственности, пока вы выбираете вариант 2.

Изменение свойств может нарушить работу MVC-приложения, но это не относится к ajax.

Answer 2

Придерживайтесь варианта 2, но есть способы проверить код. Вы можете использовать инструмент тестирования веб-приложений, например WatiN или Selenium , для проведения интеграционных тестов на ваших HTML-страницах. Кроме того, FireUnit дает вам возможность модульного тестирования кода JavaScript (для его использования вам понадобятся Firefox и Firebug).

В духе полного раскрытия я еще не пробовал MVC 2. Однако я уже некоторое время использую MVC 1 и использую эти инструменты с довольно неплохими результатами.