Бизнес логика в JavaScript.Толстый клиент против тонкого клиента

Question

Это хорошая идея для реализации бизнес-логики на стороне клиента с JavaScript?

Какая логика должна быть там? Логика валидации? Связанные с GUI?

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

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

Что ты думаешь?

Answer 1

Никогда нельзя доверять клиенту. Таким образом, любая проверка, которую вы выполняете на стороне клиента с помощью JavaScript, может только повысить удобство и удобство использования. Вы всегда должны проверять входящие данные на своем сервере позже, чтобы никто не вводил данные и т. Д.

Answer 2

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

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

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

Answer 3

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

Answer 4

'Пара (возможно, опровергнутых) заметок 2013 года:

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

Возьмите любое приложение 2+ уровня(подойдет любая обычная модель клиент-сервер);имеет ли смысл обрабатывать вещи на клиенте или на сервере?

Соображения производительности

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

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

Соображения безопасности

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

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

Иногда это означает, что на самом деле и сервер, и клиент будут проверять одни и те же данные.Хорошо.Если вы разрабатываете программное обеспечение с обеих сторон, вы можете извлечь свой проверочный код в модуль, используемый как клиентом, так и сервером (как и все эти «общие» модули в традиционных пакетах программного обеспечения).Поскольку ваш выбор языка ограничен на стороне клиента в веб-среде, вам, возможно, придется пойти на компромисс.При этом вы можете выполнить Javascript на сервере или скомпилировать многие языки вплоть до Javascript, используя такие вещи, как Emscripten (также см. Amd.js), или даже запустить собственный код в неопределенном будущем, используя такие вещи, как NaCl / PNaCl.

Заключение

Я считаю, что это помогает думать о клиентах веб-приложений как о клиентах «немедленно установленных», «без конфликтов» и «постоянно обновляемых».Мы не используем эту терминологию для Интернета, потому что эти свойства всегда были присущи классическому веб-программному обеспечению, но не для классического нативного программного обеспечения.Точно так же мы не используем такие термины, как «одностраничные приложения» при разработке собственного программного обеспечения, потому что никогда не было необходимости перезапускать все приложение, когда нам нужно было переключиться на новый экран с классическим программным обеспечением.сближение и открытость;в ближайшие годы люди из разных сообществ будут многому учиться друг у друга.

Answer 5

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

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

Удачи, и надеюсь, что это поможет некоторым.

Answer 6

За последние несколько лет я много работал с AJAX, и мое мнение таково:

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

Например, однажды у меня был самый верхний выпадающий список, который затронул пять других элементов управления под ним на странице. Вместо того чтобы выполнять отключение на стороне сервера для каждого из элементов управления, я понял, что самый верхний элемент управления сделал один вызов и управлял отображением данных на всех последующих элементах управления каскадным способом. Другие элементы управления взаимодействовали между собой с теми же данными, если только не был изменен самый верхний выпадающий список. Поэтому я создал менеджер, который кэшировал / обрабатывал данные, и производительность была превосходной! Большинство взаимодействий с пользователем было основано на этом первоначальном выпадающем списке, своего рода правило 80-20 использования. Большую часть времени они просто делали один выбор и получали то, что хотели.

• Использовать презентационную логику в клиенте. Под этим я подразумеваю, если у вас есть сортировка по выпадающему меню, которую вы можете сделать в графическом интерфейсе с помощью свойства, то это обязательно сделайте. Когда я работал с GWT в парадигме MVP (Model View Presenter), вам никогда не приходилось помещать какую-либо бизнес-логику в представление, но вам было позволено поместить туда логику представления. Это не бизнес-логика как таковая, а в хороших отношениях с другими.

Answer 7

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

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

Javascript для проверки в порядке, это уменьшит количество запросов к вашему серверу для пользователей, которые обычно используют приложение.Но это все еще подпадает под обогащение их опыта.Вам все еще нужно проверить на стороне сервера для 1% l33t h @ x0rs, которые попытаются создать проблемы.

Answer 8

Бизнес-логика должна быть максимально независимой от потребителей.При правильной разработке клиентский и серверный код должен иметь возможность использовать вашу бизнес-логику в многократном использовании (при условии, что и клиент, и сервер могут использовать javascript).

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

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

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

Также доступны микро-фреймворки, такие как peasy-js , которые помогают быстро создавать бизнес-логику, которая легко может использоваться повторно, расширяется, обслуживается и тестируется.