Логика на стороне клиента или на стороне сервера?

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

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

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

---

Отредактировано,Валя комментарии, что использование клиентской логики (с использованием Ajax/JSON) позволяет (проще) создавать API. Это вполне может быть правдой, но я могу только наполовину согласиться (именно поэтому я не проголосовал за этот ответ еще.)

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

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

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

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

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

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

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

языковые проблемы

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

---

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

чисто на стороне клиента

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

чистый на стороне сервера

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

сервер-клиент гибридных

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

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

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

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

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

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

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

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

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

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

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

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

Я вообще за серверный подход, и вот почему.

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

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

надеюсь, что это помогает.

на данном этапе стороны клиента технологии является ведущим способом, с появлением большого количества клиентских библиотек, как позвоночника, нокаут, позвоночника и затем с добавлением клиентские шаблоны, как помощью JsRender , усы и т. д., На стороне клиента развития стало значительно легко. Итак, если мое требование-перейти на интерактивное приложение, я обязательно пойду на сторону клиента. В случае, если у вас есть больше статического содержимого html, то да пойти на стороне сервера. Я сделал некоторые эксперименты, используя оба, я должен сказать, что на стороне сервера сравнительно легче реализовать тогда на стороне клиента. Что касается производительности. Прочтите это, вы поймете оценки производительности на стороне сервера. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

Я знаю, что этот пост старый, но я хотел бы прокомментировать.

по моему опыту, лучшим подходом является использование комбинации клиентской и серверной стороны. Да, Angular JS и подобные фреймворки сейчас популярны, и они облегчили разработку веб-приложений, которые имеют малый вес, улучшили производительность и работают на большинстве веб-серверов. Но основным требованием в корпоративных приложениях является отображение данных отчета, которые могут охватывать более 500 записей на одной странице. Со страницами что возвращают большие списки данных, пользователи часто хотят функциональность, которая сделает этот огромный список легко фильтровать, искать и выполнять другие интерактивные функции. Поскольку IE 11 и более ранние браузеры IE являются "браузером выбора" в большинстве компаний, вы должны знать, что эти браузеры по-прежнему имеют проблемы совместимости с использованием современных JavaScript, HTML5 и CSS3. Часто требуется сделать сайт или приложение совместимыми во всех браузерах. Это требует добавления заточки или использования прототипов, которые, с кодом, включенным для создания клиентского приложения, добавляет к загрузке страницы в браузере.

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

определить сложность приложения и то, что пользователь хочет сейчас и в будущем, основываясь на их предпочтения в существующих приложениях. Если это простой сайт или приложение с небольшими данными на носителе, используйте JavaScript Framework. Но, если они хотят включить доступность; SEO; или нужно отображать большие объемы данных, используйте серверный код для визуализации данных и клиентского кода экономно. В обоих случаях используйте такие инструменты, как Fiddler или Chrome Developer tools, чтобы проверить загрузку страницы и время отклика и использовать рекомендации по оптимизации кода.

проверка MVC приложения, разработанные с ASP.NET Ядро.

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

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

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

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

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

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

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

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

вам придется рассмотреть вопросы доступности (Поиск о веб-доступности в google) для инвалидов, но и для старых браузеров, тех, кто не имеет JavaScript, ботов (например, Google bot) и т. д.

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

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

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

удачи!