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

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

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

Если вы этого не сделаете, вы в конечном итоге со злонамеренными людьми, развращающих вашу заднюю систему.

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

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

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

' пара (возможно, самоуверенная) заметки с 2013 года:

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

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

производительности

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

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

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

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

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

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

вывод

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

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

Javascript должен использоваться для обогащения опыта пользователя в GUI, но ваш сайт / webapp все равно должен работать без него.

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

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

Я сделал много работы AJAX за последние несколько лет, и мой взгляд на это таков:

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

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

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

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

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

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

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

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