Здравствуйте, 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>На практике обычно просто пишут и там и там. Валидация это ерунда и ради неё городить какие-то замысловатые инструменты кажется излишним. Иногда надо просто скопипастить.
А потом юзер форму заполнить не может. Кто-то забыл правки на клиента внести.
