Бизнес-логика реализована на сервере.
При этом в клиентской форме надо выполнить валидацию. Как это сделать?
Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно.
А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики.
Как правильно делать в таких случаях?
Здравствуйте, 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 символов — тут да, концов не соберёшь.
Ну так следи внимательнее чтобы такого не было (глазами). Ну или используй платформу которая тебе поможет это делать автоматически, а не непойми что.
Здравствуйте, zelenprog, Вы писали:
D>>Валидация типа "есть поле в базе" — тогда только на сервере.
Z>Похожая валидация тоже нужна. Z>Например, для выполнения операции с текущим объектом надо проверить, есть ли определенные записи в БД, "связанные" с этим объектом.
Здравствуйте, Sinclair, Вы писали:
Z>>Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно. Z>>А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики. Z>>Как правильно делать в таких случаях?
S>Описывать валидацию декларативно. Те правила, которые позволяют локальное вычисление на клиенте — автоматически передавать на клиента. S>Те правила, которые требуют обращения к серверу, проверять на сервере. S>Решение о том, где какие правила проверять, должен принимать фреймворк, а не автор бизнес-логики.
В этом есть разумное зерно, но ответа нет. Допустим, у нас нет никаких фреймворков, а есть только клиент и сервер, написанные на разных языках. Что конкретно делать с этими правилами? Дважды их выполнять? Написать две имплементации обработчика правил и данных — на сервере и на клиенте?
И что значит "те правила, которые позволяют локальное вычисление на клиенте"? Как бы, на сервере в итоге должны выполняться ВСЕ правила без исключения, чтобы валидацию не отломали на другом конце. Но хорошо бы для оптимизации часть из них выполнять без запросов.
2ТС. Я тут посмотрел в DevTools'ах, во вкладке Network, на популярные мейлеры. Запросы текут рекой. Может, просто забить и делать всё на сервере? Хуже других не будешь.
Здравствуйте, zelenprog, Вы писали:
Z>Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно. Z>А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики. Z>Как правильно делать в таких случаях?
WCF RIA Services, мир праху его... Валидацию можно было вынести в shared-сборку, которая грузилась и на клиент, и на сервер. Что, спохватились? А поздно, нету его... Не оценили, не заметили, сгинул... А затем опять у них во всём Билл Гейтс виноват!
Здравствуйте, Alekzander, Вы писали:
A>В этом есть разумное зерно, но ответа нет. Допустим, у нас нет никаких фреймворков, а есть только клиент и сервер, написанные на разных языках. Что конкретно делать с этими правилами? Дважды их выполнять? Написать две имплементации обработчика правил и данных — на сервере и на клиенте?
Ну, да. Если вы живёте в 1995 году, то это — единственный правильный вариант.
1. Не делать валидацию на сервере — нельзя: клиенту мы не доверяем; мало ли кто в него какие изменения внёс.
2. Не делать на клиенте — нельзя: простейшие вещи будут тормозить, т.к. проверка — это раундтрип; типичное время ответа от бэкенда — около 2 секунд.
A>И что значит "те правила, которые позволяют локальное вычисление на клиенте"?
Это значит, к примеру, что проверки вида length(name)>0, emailRegex.IsMatch(email), и projectStartDate <= projectFinishDate нетрудно скомпилировать в язык клиента и отправить их туда, чтобы их вычисление не требовало ежесекундной передачи динамически изменяющихся данных на сервер
A>Как бы, на сервере в итоге должны выполняться ВСЕ правила без исключения, чтобы валидацию не отломали на другом конце. Но хорошо бы для оптимизации часть из них выполнять без запросов.
Я ровно про это и пишу.
Просто в 2023 году заниматься рукопашным написанием дублирующихся правил — удел любителей ретро-экзотики.
A>2ТС. Я тут посмотрел в DevTools'ах, во вкладке Network, на популярные мейлеры. Запросы текут рекой. Может, просто забить и делать всё на сервере? Хуже других не будешь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
На практике обычно просто пишут и там и там. Валидация это ерунда и ради неё городить какие-то замысловатые инструменты кажется излишним. Иногда надо просто скопипастить.
Здравствуйте, Sinclair, Вы писали:
A>>В этом есть разумное зерно, но ответа нет. Допустим, у нас нет никаких фреймворков, а есть только клиент и сервер, написанные на разных языках. Что конкретно делать с этими правилами? Дважды их выполнять? Написать две имплементации обработчика правил и данных — на сервере и на клиенте? S>Ну, да. Если вы живёте в 1995 году, то это — единственный правильный вариант. S>1. Не делать валидацию на сервере — нельзя: клиенту мы не доверяем; мало ли кто в него какие изменения внёс. S>2. Не делать на клиенте — нельзя: простейшие вещи будут тормозить, т.к. проверка — это раундтрип; типичное время ответа от бэкенда — около 2 секунд.
A>>И что значит "те правила, которые позволяют локальное вычисление на клиенте"? S>Это значит, к примеру, что проверки вида length(name)>0, emailRegex.IsMatch(email), и projectStartDate <= projectFinishDate нетрудно скомпилировать в язык клиента и отправить их туда, чтобы их вычисление не требовало ежесекундной передачи динамически изменяющихся данных на сервер
A>>Как бы, на сервере в итоге должны выполняться ВСЕ правила без исключения, чтобы валидацию не отломали на другом конце. Но хорошо бы для оптимизации часть из них выполнять без запросов. S>Я ровно про это и пишу. S>Просто в 2023 году заниматься рукопашным написанием дублирующихся правил — удел любителей ретро-экзотики.
В чём суть этого наезда с датами? "Пользуйтесь фреймворками и не задавайте глупых вопросов", или я что-то недопонял?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zelenprog, Вы писали:
Z>>Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно. Z>>А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики. Z>>Как правильно делать в таких случаях?
Pzz>И там и там, к сожалению.
Pzz>Сервер не может доверять клиенту, поэтому там должна быть полная валидация.
Неверное утверждение. Мы ничего не знаем о сети где работает клиент . Возможно это интранет компании.
В одной очень большой страховой компании вся валидация (номер телефона , email , адрес , ФИО ) выполнена на клиенте
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Janus, Вы писали:
Pzz>>Сервер не может доверять клиенту, поэтому там должна быть полная валидация.
J>Неверное утверждение. Мы ничего не знаем о сети где работает клиент . Возможно это интранет компании. J>В одной очень большой страховой компании вся валидация (номер телефона , email , адрес , ФИО ) выполнена на клиенте
Здравствуйте, zelenprog, Вы писали:
Z>Добрый день!
Z>Бизнес-логика реализована на сервере. Z>При этом в клиентской форме надо выполнить валидацию. Как это сделать?
Z>Если передавать данные на сервер для валидации — как-то это неправильно, непроизводительно. Z>А если сделать валидацию на клиенте, то это получается "размазывание" бизнес-логики. Z>Как правильно делать в таких случаях?
Клиент и сервер на одном стэке? Если да — валидацию в отдельный модуль и валидировать и там и там можно.
Вариантов много все зависит от условий задачи.
Здравствуйте, Alekzander, Вы писали:
A>В чём суть этого наезда с датами? "Пользуйтесь фреймворками и не задавайте глупых вопросов", или я что-то недопонял?
Почему же не задавайте? Задавайте.
Вот я, собственно, отвечаю на такие вопросы.
У меня просто складывается такое ощущение, что люди спрашивают что-то вроде "Чем кормить лошадь в пути из Екатеринбурга в Москву — действительно ли надо брать с собой запас овса?".
Если есть веская причина ехать именно на лошади — можно её озвучить.
Во всех остальных случаях имеет смысл выбирать между поездом и самолётом.
Если у вас на используемой платформе нет готового фреймворка для декларативной валидации, то имеет смысл приложить некоторые усилия и написать такой фреймворк самостоятельно.
С учётом того, данная задача уже была неоднократно решена в разных источниках, с нуля придётся писать не очень много — поэтому можно рассчитывать на относительно быстрый результат.
Если такие решения недоступны, то должна быть какая-то причина. Её имеет смысл озвучить при обсуждении вопроса, чтобы вам не предлагали некорректные решения. К примеру, если вы планируете участвовать в конном пробеге по РФ в рекламных целях, то никакие автомобили, поезда и самолёты вам не подойдут. Но остальные участники форума телепатией не обладают, и о таких ограничениях догадаться без вашей подсказки не смогут.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Если у вас на используемой платформе нет готового фреймворка для декларативной валидации, то имеет смысл приложить некоторые усилия и написать такой фреймворк самостоятельно. S>С учётом того, данная задача уже была неоднократно решена в разных источниках, с нуля придётся писать не очень много — поэтому можно рассчитывать на относительно быстрый результат.
Да, на "моей" платформе нет такого фреймворка. Я готов попробовать его сделать.
Можете дать ссылку где описывается как это сделать?
S>Если такие решения недоступны, то должна быть какая-то причина. Её имеет смысл озвучить при обсуждении вопроса ....
Я где-то выше писал, что платформа — это своеобразный скриптовый язык.
В нем доступны только те функции и процедуры, которые он дает "из коробки". С сервера на клиент можно передавать только примитивные типы и их массивы.
Здравствуйте, Sinclair, Вы писали:
A>>В чём суть этого наезда с датами? "Пользуйтесь фреймворками и не задавайте глупых вопросов", или я что-то недопонял? S>Почему же не задавайте? Задавайте. S>Вот я, собственно, отвечаю на такие вопросы.
S>У меня просто складывается такое ощущение, что люди спрашивают что-то вроде "Чем кормить лошадь в пути из Екатеринбурга в Москву — действительно ли надо брать с собой запас овса?". S>Если есть веская причина ехать именно на лошади — можно её озвучить.
Ну вот. Теперь заготовленная порция яда про "вы забыли спросить, но я пишу веб-сервер для кургузого GPS-приёмника, которым пользуется семейство слепых жирафов
" останется неизрасходованной. Ведь мне же МОЖНО озвучить причины! Разрешили!
S>Если такие решения недоступны, то должна быть какая-то причина. Её имеет смысл озвучить при обсуждении вопроса, чтобы вам не предлагали некорректные решения.
Ну, это уже стековерфловщина. Not a real question, closed. Обсуждается подход, и даже если он обсуждался ранее, это не повод переводить разговор на готовые решения.
Здравствуйте, zelenprog, Вы писали: Z>Я где-то выше писал, что платформа — это своеобразный скриптовый язык. Z>В нем доступны только те функции и процедуры, которые он дает "из коробки". С сервера на клиент можно передавать только примитивные типы и их массивы.
Давайте ссылку на документацию по этому языку. Посмотрим, что можно сделать
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, zelenprog, Вы писали: Z>>Я где-то выше писал, что платформа — это своеобразный скриптовый язык. Z>>В нем доступны только те функции и процедуры, которые он дает "из коробки". С сервера на клиент можно передавать только примитивные типы и их массивы.
S>Давайте ссылку на документацию по этому языку. Посмотрим, что можно сделать
Z>>Я где-то выше писал, что платформа — это своеобразный скриптовый язык. Z>>В нем доступны только те функции и процедуры, которые он дает "из коробки". С сервера на клиент можно передавать только примитивные типы и их массивы.
S>Давайте ссылку на документацию по этому языку. Посмотрим, что можно сделать
bnk>Он почему-то не хочет говорить
Это 1С. Надо в 1С сделать пару обработок.
Архитектура 1С навязывает свое разделение кода на "физические" tiers: на сервер и клиент.
Однако, кроме этого физического разделения, при большом количестве строк кода, нужно еще делить код и на "логические" layers.
Возник вопрос по валидации. Поэтому в данной теме я и поднял этот вопрос.
, я уже спрашивал
Z>Ох, ребята, не терзайте мне душу.
Z>Это 1С. Надо в 1С сделать пару обработок. Z>Архитектура 1С навязывает свое разделение кода на "физические" tiers: на сервер и клиент. Z>Однако, кроме этого физического разделения, при большом количестве строк кода, нужно еще делить код и на "логические" layers. Z>Возник вопрос по валидации. Поэтому в данной теме я и поднял этот вопрос.
Ну так и сказал бы сразу. Ничего смешного тут нет
Мне все еще кажется фильтровать (кодом) или как-то подсвечивать дубликаты в такой системе будет проще, чем делать приложение для слияния баз.
Здравствуйте, vsb, Вы писали:
vsb>На практике обычно просто пишут и там и там. Валидация это ерунда и ради неё городить какие-то замысловатые инструменты кажется излишним. Иногда надо просто скопипастить.
А потом юзер форму заполнить не может. Кто-то забыл правки на клиента внести.
