Клиентская логика логической ИЛИ Серверной стороны?

Я предпочитаю логику на стороне сервера. Мои причины довольно просты:

1. Я не доверяю клиенту; это может быть или не быть настоящей проблемой, но обычно
2. Серверная сторона уменьшает объем каждой транзакции (хотя и увеличивает количество транзакций)
3. Серверная сторона означает, что я могу быть вполне уверен в том, что такое логика имеет место (мне не нужно беспокоиться о движке Javascript, доступном для клиентского браузера)

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

Я понимаю логику на стороне сервера как логику, которая извлекает данные и организует их; если я правильно понял, логика - это «контроллер» (C в MVC). И это затем передается «взгляду». Я обычно использую контроллер для получения данных, а затем «представление» занимается их представлением пользователю / клиенту. Поэтому я не вижу, чтобы различия между клиентом и сервером обязательно имели отношение к аргументу создания API, в основном: лошади для курсов. :)

... также, как любитель, я понимаю, что у меня может быть несколько искаженное использование MVC, поэтому я готов поправиться по этому поводу. Но я по-прежнему держу презентацию отдельно от логики. И это разделение является плюсом для API.

Обычно я реализую как можно больше на стороне клиента. Единственными исключениями, которые заставили бы меня перейти на сервер, было бы решение следующих проблем:

Проблемы с доверием

Любой человек может отлаживать JavaScript, читать пароли и т. Д. Здесь нет ничего сложного.

Проблемы с производительностью

] Механизмы JavaScript быстро развиваются, так что это становится меньшей проблемой, но мы все еще живем в мире, где доминирует IE, поэтому работа будет замедляться, когда вы имеете дело с большими наборами данных.

Проблемы с языком

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

Судя по вашему вопросу, это похоже на вас ». re просто пытается загрузить значения в форму. Если исключить любую из вышеперечисленных проблем, у вас есть 3 варианта:

Чистая клиентская сторона

Недостатком является то, что время загрузки ваших пользователей удвоится (одна загрузка пустой формы, другая загрузка данных). Однако последующие обновления формы не потребуют обновления страницы. Пользователям это понравится, если с сервера будет загружаться много данных в той же форме.

Чисто на стороне сервера

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

Гибрид сервер-клиент

У вас будет лучшее из обоих миров, однако вам нужно будет создать две точки извлечения данных, что приведет к ваш код слегка раздувается.

Одно соображение, о котором я не слышал, касалось пропускной способности сети. Чтобы привести конкретный пример, приложение, с которым я работал, было полностью выполнено на стороне сервера и привело к отправке веб-страницы размером 200 МБ на клиент (было невозможно сделать меньше без серьезного изменения дизайна группы приложений); в результате время загрузки страницы составляет 2-5 минут.

Когда мы повторно реализовали это, отправив данные в кодировке JSON с сервера и заставив локальный JS генерировать страницу, основным преимуществом было то, что отправленные данные сократились до 20 МБ, результат:

• Размер HTTP-ответа: 200 МБ + => 20 МБ + ( с соответствующей экономией полосы пропускания !)

• Время загрузки страницы: 2-5 минут => 20 секунд (10-15 из которых занятые запросом к БД, который был оптимизирован и дальше к черту).

• Размер процесса IE: 200 МБ + => 80 МБ +

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

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

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

Я создал веб-приложение RESTful, в котором все функции CRUD доступны в отсутствие JavaScript, другими словами, все эффекты AJAX являются строго прогрессивными улучшениями ].

Я считаю, что при достаточной самоотдаче большинство веб-приложений можно спроектировать таким образом, тем самым разрушив многие различия между логикой сервера и клиентской логикой, такие как безопасность и расширяемость, поднятые в вашем вопросе, потому что в обоих случаях запрос направляется к тому же контроллеру, бизнес-логика которого остается неизменной до последней мили, где для этих XHR возвращается JSON / XML вместо HTML всей страницы.

Только в некоторых случаях, когда AJAXified приложение намного более продвинуто, чем его статический аналог, и GMail - лучший пример, который приходит мне на ум,затем нужно создать две версии и полностью разделить их (Слава Google!).

Думаю, второй вариант лучше. Например, если вы позже реализуете что-то вроде «скинов», вы будете благодарить себя за то, что не отформатировали html на сервере :)

Это также сохраняет разницу между представлением и контроллером. Данные Ajax часто создаются контроллером, поэтому пусть он просто возвращает данные, а не html.

Если вы собираетесь создать API позже, вам нужно будет внести в свой код очень мало изменений

Кроме того, Я думаю, что «голые» данные более кэшируемы, чем HTML. Например, если вы добавите стиль к ссылкам, вам нужно будет переформатировать весь html .. или добавьте одну строчку в свой js. И он не такой большой, как html (в байтах).

Но если для форматирования данных требуется много тяжелых сценариев, нехорошо просить браузеры пользователей отформатировать их.

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

С другой стороны, если вам нужно обработать большой объем данных, чтобы создать крошечный объем HTML для отправки клиенту, или если можно сделать оптимизацию для использовать работу сервера для поддержки множества клиентов одновременно (например, обработать данные один раз и отправить полученный HTML-код всем клиентам), тогда это может быть более эффективным использованием ресурсов для выполнения работы на этом сервере.

Я хотел бы отдать свои два цента по этому поводу.

В целом я сторонник серверного подхода, и вот почему.

• Более дружественный к SEO . Google не может выполнять Javascript, поэтому весь этот контент будет невидим для поисковых систем
• . Производительность более управляема. Взаимодействие с пользователем всегда меняется с SOA из-за того, что вы почти полностью полагаетесь на браузер и компьютер пользователя для визуализации вещей. Даже если ваш сервер может работать хорошо, пользователь с медленным компьютером будет думать, что ваш сайт виноват.
• Возможно, серверный подход легче поддерживать и читать.

Я написал несколько систем, использующих оба подхода, и по моему опыту, серверная сторона - это лучший способ. Однако это не значит, что я не использую AJAX. Все современные системы I '

Если вы сделаете это в Ajax:

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

Вам придется поиграть с «прогрессивным улучшением», что непросто сделать, если вы никогда не работали с JavaScript много. Короче говоря, вам придется заставить свое приложение работать со старыми браузерами и теми, в которых нет JavaScript (например, некоторые мобильные) или если он отключен.

Но если время и деньги не являются проблемой, я бы пойти с прогрессивным улучшением.

Но также рассмотрите «кнопку возврата». Ненавижу, когда просматриваю веб-сайт со 100% AJAX, который делает вашу кнопку «Назад» бесполезной.

Удачи!