Отделение логики на стороне клиента от логики на стороне сервера путем многократного использования с использованием MVC

Question

Прежде чем ответить, этот вопрос сложный:

1. Мы разрабатываем в asp.net / asp.net mvc / jQuery, но я открыт для решений на любой платформе, использующих любой фреймворк
2. Я думаю, что логика, такая как сортировка / скрытие столбцов / реорганизация столбцов / проверка (где это имеет смысл) должна быть на стороне клиента
3. Я думаю, что логика, такая как поиск / обновление БД / выполнение рабочих процессов, должна выполняться на стороне сервера (только из соображений безопасности / отладки)

То, что мы пытаемся сделать, это НЕ СОЗДАТЬ MESS в нашем пользовательском интерфейсе, написав несколько JavaScript для работы с одной и той же функцией в разных контекстах. Я понимаю, что могу использовать файл JavaScript + объектно-ориентированный JavaScript, я ищу шаблон, который облегчит все это.

Одним из предложенных решений было использование модели MVC как на стороне клиента, так и на стороне сервера, где мы можем инкапсулировать функциональность JavaScript в контроллерах на стороне клиента, а затем использовать их в разных частях сайта. Однако это означает, что у нас есть 2 реализации MVC!

Это перебор? Как бы вы расширили это решение? Какие еще есть решения?

Answer 1

Будьте проще. Создайте свое приложение, чтобы оно было полностью функциональным в среде 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 и сервер, мог использовать одни и те же функции / данные.

Answer 2

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

Answer 3

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

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

Я не знаю, как работает 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-запросы на новые страницы, если пользователь нажимает кнопку следующей страницы, а также обрабатывает столбцы и сортировку (которая также делегирует серверу).

Answer 4

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

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

Answer 5

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

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

Answer 6

... Это зависит ...

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

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

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

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