Как избежать повторения бизнес-логики между клиентом и сервером?

По мере роста потребностей веб-приложений я обнаружил, что пишу больше и больше веб-приложений, управляемых API. Я использую фреймворки, такие как AngularJS, для создания богатых веб-клиентов, которые общаются с этими API. В настоящее время я использую PHP (Lumen или Laravel) для серверной части /API.

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

Когда я говорю бизнес-логику, я имею в виду следующие правила для формы заказа:

Вы можете купить X, если вы покупаете Y.
Вы не можете купить Y, если у вас есть Z.
Если вы купите 10 из них, вы получите скидку 10%.
Высота x Ширина x Глубина x Стоимость = Окончательная стоимость.
Высота должна быть от 10 до 20, если ваша ширина больше 5.
и т.д.

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

У меня есть три решения:

Сделать все, что требует бизнес-логики, сделать аякс-вызов API. Вся бизнес-логика будет жить в одном месте и может быть проверена один раз. Это может быть медленным, так как клиенту придется ждать каждого изменения, которое они вносят в форму заказа, для получения обновленных значений и результатов. Благодаря этому очень быстрый API. Основной недостаток заключается в том, что это может не сработать, когда пользователи плохо подключены (мобильные устройства).
Напишите бизнес-логику на стороне клиента И на стороне сервера. Клиент получает мгновенную обратную связь, поскольку они вносят изменения в форму, и мы проверяем все данные после их отправки на сервер. Недостатком здесь является то, что мы должны дублировать всю бизнес-логику и тестировать обе стороны. Это, безусловно, больше работы и сделает будущую работу хрупкой.
Доверяйте клиенту!?! Напишите всю бизнес-логику на стороне клиента и предположите, что они не вмешиваются в данные. В моем текущем сценарии я работаю над создателем цитат, который всегда будет проверяться человеком, поэтому, возможно, это действительно нормально.

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

Ответ 1

Вы можете сделать еще одну вещь.

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

Затем установите сервер nodejs рядом с сервером PHP, чтобы обслуживать эту логику на стороне клиента. Так что на стороне клиента он может использоваться без вызова AJAX.

Затем с серверной стороны (PHP), когда вам нужно проверить и запустить всю эту бизнес-логику, вызовите cURL nodejs для проверки этих данных. Это означает, что это HTTP-вызов с сервера PHP на сервер nodejs. Сервер Nodejs будет иметь другой код, который будет принимать эти данные и проверять с помощью того же кода и возвращать результат.

Таким образом вы можете сделать

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

Только то, что вам нужно сделать, это настроить nodejs рядом с сервером PHP. Но вам не нужно менять весь свой код на сервер nodejs.

Ответ 2

У меня была такая же проблема, когда я решил создать приложение с использованием Laravel для back end и Angular 2 для front-end. И мне кажется, что нет решения избежать дублирования бизнес-логики до сих пор, потому что:

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

Чтобы достичь цели, мы должны написать бизнес-логику только на одном языке, и до сих пор JavaScript является лучшим решением. Как вы знаете, TypeScript/EMCA Script поможет нам написать код в пути ООП. Meteor framework Инфраструктура NodeJS помогает нам писать код в JavaScript для работы в обеих сторонах Back-end и front-end.

Итак, с моей точки зрения, мы можем использовать TypeScript/EMCA для написания пакетов для бизнес-логики, например, класс для проверки, написанный на JavaScript, может быть реализован с обеих сторон, поэтому вы просто пишете только одно время, но это будет вызываться дважды из интерфейсного и back-end также.

Это моя точка. Надеюсь увидеть некоторые другие решения для этой очень интересной темы.

Ответ 3

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

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

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

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

Вот некоторые из распространенных проблем, с которыми мне пришлось иметь дело:

Ошибка интерфейса переднего интерфейса, если API возвращает один?
Если пользователь допустил ошибку и представил форму, он/она должен увидеть ошибку. Но как только пользователь исправил ошибку и отправил ее снова, сообщение об ошибке должно скрываться, и сообщение об успешном запуске должно теперь отображаться.
Что делать, если API не работает или интернет-соединение нестабильно, поэтому ничего не возвращается. Будет ли интерфейс висит?
Что делать, если есть несколько сообщений об ошибках, может ли/внешний интерфейс отображать их все?

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

Ответ 4

Одним из возможных решений является объявление ваших правил проверки в декларативном абстрактном языке, таком как XML или JSON Schema.

Затем, на стороне клиента, скажем, AngularJS - вы можете преобразовать эти правила в средство рендеринга полки. Итак, теперь на стороне клиента вы получаете формы, которые подтверждают объявленные правила.

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

В конце концов, это одно место, ваша схема JSON или когда вы декларативно определяете свои правила, что ваши формы и правила проверки определены.

Ответ 5

Я чувствую, что вариант 1 - лучший шаг вперед в будущем. Первая разработка API позволяет проверять и работать всю бизнес-логику и разрешать доступ к интерфейсам. Никогда НИКОГДА не доверяйте пользователю!

Первая разработка power API не ограничена по сравнению с повторением одной и той же логики снова и снова для каждого необходимого интерфейса.

Ответ 6

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

Клиентская сторона и серверная сторона

Ответ 7

Прежде всего: никогда не доверяйте клиенту.

Говоря это, я все время общаюсь с этим, и, к сожалению, я не нашел легкого решения. Вам нужно сделать валидацию с обеих сторон, НО, вам не нужно делать всю проверку на них обоих.

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

Теперь, как сделать так, чтобы, когда вам нужно что-то менять, вам не нужно менять его с обеих сторон? Ну, иногда вы не сможете избежать этого, когда требуются серьезные изменения, НО, параметры бизнес-логики могут быть разделены, и, как вы сказали, это можно сделать через ajax. Вы создаете файл php, где у вас есть все параметры бизнес-логики, и с помощью запроса ajax вы загружаете это на стороне клиента, только один раз (когда загружается script), вам нужно оптимизировать это, так что вы получаете только значения параметров, все остальное должно быть уже на стороне клиента, поэтому, если какое-то значение параметра в бизнес-логике изменяется, вы изменяете его только в файле параметров. (Если параметр был изменен после загрузки script, проверка на сервере не будет завершена, теперь вам нужно решить, заставляете ли вы их загружать script, поэтому параметры переопределяются или нет, я заставляю их перезагружать их)

Я думаю, вы поняли. Это то, что я делаю, и это работает хорошо для меня, экономит много перекодировки.

Надеюсь, вы сочтете это полезным.