Бизнес-логика реализована на сервере.
При этом в клиентской форме надо выполнить валидацию. Как это сделать?
Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно.
А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики.
Как правильно делать в таких случаях?
Здравствуйте, zelenprog, Вы писали:
Z>Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно. Z>А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики. Z>Как правильно делать в таких случаях?
По идее первичная вылидация делается на клиенте, если с точки зрения клиента они верны, то передаются серверу и там перепроверяются на всякий случай на предмет того, что клиент не хакнули.
Здравствуйте, zelenprog, Вы писали: Z>Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно. Z>А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики. Z>Как правильно делать в таких случаях?
Описывать валидацию декларативно. Те правила, которые позволяют локальное вычисление на клиенте — автоматически передавать на клиента.
Те правила, которые требуют обращения к серверу, проверять на сервере.
Решение о том, где какие правила проверять, должен принимать фреймворк, а не автор бизнес-логики.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Решение о том, где какие правила проверять, должен принимать фреймворк, а не автор бизнес-логики.
А это как? Объясните поподробнее пожалуйста.
Программа пишется на скриптовом языке с поддержкой ООП, и фреймворка никакого нету.
Грубо говоря, есть только "платформа", выполняющая скрипты.
Здравствуйте, zelenprog, Вы писали:
S>>Решение о том, где какие правила проверять, должен принимать фреймворк, а не автор бизнес-логики.
Z>А это как? Объясните поподробнее пожалуйста. Z>Программа пишется на скриптовом языке с поддержкой ООП, и фреймворка никакого нету. Z>Грубо говоря, есть только "платформа", выполняющая скрипты.
Если нет никакой поддержки "платформы" то, очевидно, только дублировать на клиенте и сервере?
Здравствуйте, zelenprog, Вы писали:
Z>Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно. Z>А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики. Z>Как правильно делать в таких случаях?
И там и там, к сожалению.
Сервер не может доверять клиенту, поэтому там должна быть полная валидация.
Валидация на клиенте нужна, в основном, чтобы увеличить комфорт пользователя (быстрее сообщить ему об ошибках).
Кстати, если есть какие-то параметры, которые, из соображений безопасности, нежелательно, чтобы клиент мог подобрать — не надо передавать на сторону клиента информацию, облегчающую их подбор.
Здравствуйте, Sinclair, Вы писали:
S>Решение о том, где какие правила проверять, должен принимать фреймворк, а не автор бизнес-логики.
Почему?
Это вообще, по-моему, опасная игра. Она кажется разумной, пока всё работает. А вот когда сломается, концов не соберешь. На мой взгляд, все важные решения должены явно приниматься кодом, являющимся частью кодовой базы проекта, а не фреймворками.
Здравствуйте, zelenprog, Вы писали:
Z>Как правильно делать в таких случаях?
Валидация типа "есть поле в базе" — тогда только на сервере.
Валидация типа "строчка похожа на емейл" — и на клиенте, и на сервере.
Чтобы не "размывать" логику валидации можно с сервера передавать js-скриптик валидации (и его же, конечно, использовать, и на сервере для валидации).
Здравствуйте, Pzz, Вы писали: Pzz>Почему?
Потому что автору бизнес логики есть о чём думать, кроме выбора места для проверки правил. Pzz>Это вообще, по-моему, опасная игра. Она кажется разумной, пока всё работает. А вот когда сломается, концов не соберешь.
Pzz>На мой взгляд, все важные решения должны явно приниматься кодом, являющимся частью кодовой базы проекта, а не фреймворками.
Ну пусть этот код будет частью проекта. Но не в каждом месте, а в некой платформенной части, которая обрабатывает декларативную разметку.
Если "всё сломалось" — значит, в это общем есть бага, которую надо починить, и всё заработает.
А вот когда рукопашный валидатор в JS требует пароль не меньше 8, бизнес-логика на сервере зарубает кириллицу, а в БД стоит ограничение на 16 символов — тут да, концов не соберёшь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Потому что автору бизнес логики есть о чём думать, кроме выбора места для проверки правил.... S>Ну пусть этот код будет частью проекта. Но не в каждом месте, а в некой платформенной части, которая обрабатывает декларативную разметку.
Но автору бизнес-логики надо думать над самими правилами.
И где-то их нужно все-таки разместить, в каком-то одном месте.
А "работу" по этим правилам конечно должна выполнять платформа (по вашей терминологии — фреймворк).
Так вот где надо разместить? Как правильно это сделать?
Чтобы бизнес-логика, "размазанная" на два звена (tiers) имела правила в одном месте и проверяла их без лишних непроизводительных передач данных с клиента на сервер?
bnk>Если нет никакой поддержки "платформы" то, очевидно, только дублировать на клиенте и сервере?
Да, никакой поддержки платформы нету.
Как правильно сделать валидацию с учетом этого обстоятельства?
S>А вот когда рукопашный валидатор в JS требует пароль не меньше 8, бизнес-логика на сервере зарубает кириллицу, а в БД стоит ограничение на 16 символов — тут да, концов не соберёшь.
Я тоже против этого.
Именно поэтому и создал эту тему, чтобы выяснить как надо сделать.
Как я понимаю, код, реализованный и на клиенте и на сервер — это код бизнес-логики. Верно?
То есть получается, слой бизнес-логики будет "разделенный", "размазанный" на два звена (tiers) — клиент и сервер.
D>Валидация типа "строчка похожа на емейл" — и на клиенте, и на сервере.
Да, такая валидация нужна в первую очередь.
D>Чтобы не "размывать" логику валидации можно с сервера передавать js-скриптик валидации (и его же, конечно, использовать, и на сервере для валидации).
А если нет возможности передавать скрипт? Платформа не поддерживает.
Может быть передать структуру данных, в которой задается параметры валидации?
D>Валидация типа "есть поле в базе" — тогда только на сервере.
Похожая валидация тоже нужна.
Например, для выполнения операции с текущим объектом надо проверить, есть ли определенные записи в БД, "связанные" с этим объектом.
Здравствуйте, zelenprog, Вы писали:
D>>Валидация типа "строчка похожа на емейл" — и на клиенте, и на сервере. Z>Да, такая валидация нужна в первую очередь.
И всё равно её делать в двух местах, се ля ви.
D>>Чтобы не "размывать" логику валидации можно с сервера передавать js-скриптик валидации (и его же, конечно, использовать, и на сервере для валидации).
Z>А если нет возможности передавать скрипт? Платформа не поддерживает.
Это как? Платформа поддерживает запрос и ответ, значит, может ответить телом скрипта.
Z>Может быть передать структуру данных, в которой задается параметры валидации?
"Параметры валидации" будут написаны на каком-то языке программирования. А чем изобретать собственный, проще использовать имеющися.
Для проверки на емейл можно и регеспом пользоваться, но какая разница, передавать с бэкэнда регексп или джаваскриптовый код?
Z>Например, для выполнения операции с текущим объектом надо проверить, есть ли определенные записи в БД, "связанные" с этим объектом.
Тогда при вытаскивании текущего объекта вытаскивать и связанные тоже, они закэшированы на клиенте и клиент может их по ним быстро валидировать.
Здравствуйте, zelenprog, Вы писали:
Pzz>>И там и там, к сожалению.
Z>Как я понимаю, код, реализованный и на клиенте и на сервер — это код бизнес-логики. Верно? Z>То есть получается, слой бизнес-логики будет "разделенный", "размазанный" на два звена (tiers) — клиент и сервер.
Ну а что делать-то?
Можно попробовать сделать эти проверки пригодными для для использования и на клиенте и на сервере (например, это возможно, если и там и там используется JS) или генерировать их из какого-то общего исходника, параметризовать правилами и т.п.
Но содержательно, надо проверять и там и там. Иметь дублирование кода, разумеется, не хотелось бы.
D>Это как? Платформа поддерживает запрос и ответ, значит, может ответить телом скрипта.
Платформа может ответить данными: строкой, или структурой данных — набором строк или других примитивных типов.
Но клиент не "понимает", что эта строка — это скрипт.
Он понимает это просто как строку. Не умеет платформа выполнять строки, которые представляют собой код на этой же самой платформе.
Z>>Например, для выполнения операции с текущим объектом надо проверить, есть ли определенные записи в БД, "связанные" с этим объектом. D>Тогда при вытаскивании текущего объекта вытаскивать и связанные тоже, они закэшированы на клиенте и клиент может их по ним быстро валидировать.
Хм... Тогда придется на клиента слишком большой кэш передавать.
Так как на клиент передается таблица с записями товаров, и над каждым товаром надо выполнить некоторую операцию.
Операция эта возможна только если товар находится в определенном состоянии (валидация).
Получается, на клиенте для каждой записи товара в таблице товаров надо хранить и кэш, связанный с валидацией?
Тогда тут сложность возникает с тем, что надо поддерживать этот кэш в актуальном состоянии, с учетом внесения изменений в базу со стороны других клиентов.
Слишком сложно получается...
Здравствуйте, zelenprog, Вы писали:
D>>Это как? Платформа поддерживает запрос и ответ, значит, может ответить телом скрипта.
Z>Платформа может ответить данными: строкой, или структурой данных — набором строк или других примитивных типов. Z>Но клиент не "понимает", что эта строка — это скрипт.
Так можно же научить, мыжпрограммисты.
Z>Слишком сложно получается...
Тогда проверки на бэкэнде, проигрывая в производительности
bnk>>Если нет никакой поддержки "платформы" то, очевидно, только дублировать на клиенте и сервере?
Это был не совсем вопрос, вопросительный знак скорее для вежливости
Z>Да, никакой поддержки платформы нету. Z>Как правильно сделать валидацию с учетом этого обстоятельства?
S>>А вот когда рукопашный валидатор в JS требует пароль не меньше 8, бизнес-логика на сервере зарубает кириллицу, а в БД стоит ограничение на 16 символов — тут да, концов не соберёшь.
Ну так следи внимательнее чтобы такого не было (глазами). Ну или используй платформу которая тебе поможет это делать автоматически, а не непойми что.
