Разделение логики на стороне клиента от логики на стороне сервера многократно используемым способом с использованием MVC

на двоих; у вас всегда должна быть проверка на стороне сервера, а также проверка на стороне клиента

на три; если бы вы могли найти способ манипулировать БД на стороне клиента, это было бы впечатляюще;)

Я не знаю, как работает ASP.net, поэтому я говорю исключительно о своем опыте работы с PHP.

Я бы написал элементы управления, которые объединены серверным и клиентским кодом. Каждому элементу управления нужна форма, логика на стороне клиента и логика на стороне сервера. Форма записывается вашим механизмом шаблонов, логика на стороне клиента прикреплена к форме и написана на JS, а логика на стороне сервера представляет собой пару контроллер/действие где-то, которая манипулирует моделью. Очевидно, что вы не хотели бы связывать логику своей клиентской стороны с конкретным действием/контроллером, поэтому обязательно определите интерфейс, который можно использовать для взаимодействия с вашим элементом управления...

Затем для каждой формы я бы написал класс в javascript, который содержит ваши элементы управления. Например; у вас может быть контроль:

{include file = "list_view.php" id = "ListView1" data = $Data.List}

который распечатает вашу форму. Затем в вашем классе контроллера страницы:

this.ListView1 = new ListViewController({id : "ListView1", serverCtrl : "Users"});

Теперь вы можете использовать this.ListView1 для управления представлением списка. Контроллер представления списка делает такие вещи, как запросы AJAX для новых страниц, если использование нажимает кнопку следующей страницы, а также обрабатывает столбцы и сортировку (которая также будет делегирована серверу).

Я только что погуглил это, так что принимайте это с недоверием. JavascriptMVC претендует на роль платформы MVC. Опять же, у меня нет опыта с этим, но, возможно, стоит посмотреть.

Будь проще. Создайте полнофункциональное приложение в среде MVC ASP.Net. На данном этапе тестирования JavaScript не требуется.

Теперь добавьте приятные вещи, связав jQuery в своем site.master (ссылка Google) и в нижней части ваших представлений, которые требуют работы с веб 2.0, ссылку на соответствующие файлы JS, которые ненавязчиво добавляют функциональность. Выключите JS, и ваше приложение вернется к предыдущему шагу.

Например, вы хотите добавить проверку на стороне клиента в дополнение к проверке на стороне сервера. Файл JS будет прикреплять обработчик событий к формам при отправке. Затем обработчик будет использовать объект, созданный сервером (тот же объект, который используется для проверки сервера), который лучше всего подходит в качестве объекта JSON, поскольку он совместим с JS и ASP.NET. Членами объекта будут правила для проверки и сообщения об ошибках для записи в DOM в том же месте, которое вы выбрали для ошибок на стороне сервера. Ваш обработчик возвращает false до тех пор, пока все не станет действительным и истинным, если оно верно.

Вам нужна приятная причудливая функция, такая как просмотр ваших изображений в лайтбоксе. Добавьте плагин для своего вида, измените разметку <ul id="lightup">..., добавьте код:

$(function() {
   $(#lightup).showit(400); // or something like that
});

и вам хорошо идти.

Попробуйте отделить общие функции от кода вашего сервера в веб-службу или страницу, чтобы и клиент через XHR, и сервер могли совместно использовать одни и те же функции/данные.

Если вы используете MVC, то я предполагаю, что ваше представление использует механизм шаблонов. Каждая страница связана с шаблоном, и каждый шаблон обычно содержит ссылку на один или несколько сценариев. Вопрос в том, как ваши сценарии упоминаются в шаблоне? Статичны они или динамичны? В ваших контроллерах у вас должна быть возможность включать любые сценарии в представление, используемое для страницы, независимо от шаблона. Я часто предлагаю этот подход "включить его, когда это необходимо", потому что симуляция MVC на стороне клиента означает именно то, что вы сказали, - теперь у вас есть две инфраструктуры MVC, которые нужно поддерживать. Мало того — в большинстве моделей на стороне клиента они имеют прямой доступ к вашей модели на стороне сервера, что противоречит цели вашего MVC на стороне сервера. Теперь вы полностью обходите контроллер.

Когда дело доходит до JavaScript, лучше всего сделать его очень простым. С jQuery у вас есть еще больше шансов добиться этого. Каждая страница получает ядро, и у вас есть несколько других файлов JavaScript в той же папке, каждый из которых является плагином или расширением объекта jQuery, который отображает очень специфическую функциональность. Если разработчики хотят знать, существует ли функциональность, все, что вам нужно сделать, это проверить файловую систему, в которой расположены файлы JavaScript. Если плагин существует, включите его в свой контроллер для использования на странице. Таким образом, вы можете создавать помощники на стороне сервера, которые находятся между вашим клиентским приложением и любыми существующими контроллерами. Помощник специфичен для этой функциональности и плагина, и вы не открываете полный доступ к своим моделям со стороны клиента.

не возвращайте json/xml в представления и не создавайте их с генерацией jquery dom на клиенте. Это нормально с точки зрения производительности на приличных машинах, но я допустил эту ошибку, и при попытке просмотра сайта с моего iphone загрузка занимает 60 секунд ... и я единственный человек на сайте! :-)

поэтому на данный момент я просто использую инъекцию jquery dom для обновлений ajaxy, а не рендеринг всей страницы.

... По-разному...

На самом деле лучше всего разрабатывать пользовательский интерфейс с использованием css/javascript/html для стиля/поведения/структуры + данных, в наши дни люди хотят взаимодействия с ajax (они видят эти крутые вещи повсюду, поэтому они ожидают, что им не нужно перезагружать целые страницы каждый раз), так что я думаю, вы должны принять это во внимание. Кстати, MVC заканчивается, когда ваш контент обслуживается, и он не должен быть HTML-контентом, вы можете обслуживать xml или json в своем представлении.

ASP.NET MVC разрешает возвращать Content ("TEXT"), поэтому вы можете организовать свою серверную часть с помощью MVC и взаимодействия/поведения пользователя в javascript, например, когда вызов ajax отправляется на сервер, который вы вызываете. Часть контроллера вашего приложения , поэтому вы можете вызывать действие Ajax, которое переключается на модель ajax, которая отображается как JSON и возвращается к JS-части вашего пользовательского интерфейса (поведенческая часть).

Поскольку часть Behavioral определена в части View (первоначальный View состоит из CSS/HTML JS), пока это презентационная часть, я думаю, вы не нарушили шаблоны MVC.

PS. Я забыл сказать, что, очевидно, действия БД остаются в вашей модели (вы можете думать о модели как о месте, где остаются уровень доступа к данным + уровень бизнес-объектов)