Разрабатываем систему на (ASP.NET)
В системе есть слой бизнес-логики, и каждый объект должен проходить некую проверку (валидацию).
причем многие проверки являются скорее перекрестными правилами.
"Если договор заключен до 30 июня, то в приложении к нему (связанный объект) должен присутствовать документ с маркером ABC"
"Если задание было выполнено подразделением X, то в поле Y должна быть подпись Карла и еще в пакете должен присутствовать договор с организацией Z на сумму не менее чем 100 рублей"
Не слишком наглядно, но принцип думаю понятен. Правил много (десятки-сотни).
Как обычно реализуется такая логика валидации?
Насколько я вижу, есть варианты
1. Писать код. Самый очевидный подход, но не очень гибкий.
При изменении правил код придется менять, деплоить-обновлять приложение, что есть рестарт/остановка сайтов/сервисов, что есть нехорошо.
Также для изменения кода нужны программисты, что также не слишком здорово.
2. Построить какой-то свой фреймворк для описания правил и переметризировать правила выше чтением неких конфиг-файлов.
Не нравится то что это задача-в-задаче, и вместо того, чтобы делать дело мы разрабатываем свой велосипед.
3. Использовать стандартный фремворк для валидации (какой посоветуете?)
Все что я видел (типа валидации ASP.NET MVC, Enterprise Library (EL) Validation Block, ну и всякие прочие валидации,
которые идут с библиотеками, как правило заточены на достаточно простой случай (типа длины строки или периода времени).
Это тоже нужно, но как быть с правилами вроде приведенных выше, не очень понятно. Например чтобы в той же EL (написанной архитектурными астронавтами походу)
описать что-то более-менее сложное-составное, это же серьезно обкуриться надо, да и это вряд ли поможет.
4. Использовать некий скриптовый язык, и иметь правила валидации на нем.
Например использовать как-то Roslyn в виде скрипта. Как это проще сделать и на чем?
Валидируемые сущности — это по сути обычные объекты. Они должны быть доступны из скрипта.
Здравствуйте, bnk, Вы писали:
bnk>Как обычно реализуется такая логика валидации?
1. Реализуется механика локальных транзакций.
2. Объектам даётся API для отлова момента "готовимся к коммиту"
3. В обработчике делаем нашу валидацию.
4. Для сложных биз-процессов добавляем проверки по всему коду, отладочными ассертами.
Для решения проблемы "надо рестартить" есть куча вариантов, простейший — несколько аппулов с поэтапным деплоем.
bnk>При изменении правил код придется менять, деплоить-обновлять приложение, что есть рестарт/остановка сайтов/сервисов, что есть нехорошо. bnk>Также для изменения кода нужны программисты, что также не слишком здорово.
А для всех остальных случаев, кроме валидации, что делать планируется? Бизнес-логика у вас же не заканчивается на валидации, так?
Если ничего делать не планируется — то да, код правил в базе + кэш с скомпилированными скриптами. Если "чего" — вам точно нужен человек, который проектировал и сопровождал подобные системы на практике.
Здравствуйте, bnk, Вы писали:
bnk>4. Использовать некий скриптовый язык, и иметь правила валидации на нем. bnk>Например использовать как-то Roslyn в виде скрипта. Как это проще сделать и на чем? bnk>Валидируемые сущности — это по сути обычные объекты. Они должны быть доступны из скрипта.
Я скорее за такой вариант. Часто делают скриптовые расширения на луа, питоне. Можно менять валидацию на продакшне, при этом ничего не перезапуская
С другой стороны, отлаживать встроенные скрипты может оказаться довольно непростым делом.
Здравствуйте, Sinix, Вы писали:
S>1. Реализуется механика локальных транзакций. S>2. Объектам даётся API для отлова момента "готовимся к коммиту" S>3. В обработчике делаем нашу валидацию. S>4. Для сложных биз-процессов добавляем проверки по всему коду, отладочными ассертами.
S>Для решения проблемы "надо рестартить" есть куча вариантов, простейший — несколько аппулов с поэтапным деплоем.
bnk>>При изменении правил код придется менять, деплоить-обновлять приложение, что есть рестарт/остановка сайтов/сервисов, что есть нехорошо. bnk>>Также для изменения кода нужны программисты, что также не слишком здорово. S>А для всех остальных случаев, кроме валидации, что делать планируется? Бизнес-логика у вас же не заканчивается на валидации, так?
Спасибо за ответ.
Я правильно понимаю, ты советуешь по сути 1 вариант — не выпендриваться и писать код?
Кодируя все правила бизнес-логики и валидации. Проблемы деплолймента решать соответствующими методами.
Еще, в качестве пояснения — в нашем случае "объекты" в "сломанном" состоянии могут быть вполне легальны,
но нужна возможность понять, что какое-то правило нарушено (иметь список "сломанных" правил)
S>Если ничего делать не планируется — то да, код правил в базе + кэш с скомпилированными скриптами.
Можно здесь поподробнее. Что значит код правил в базе? Компиляция и кэширование каких скриптов имеется в виду?
Тут еще что, базы как таковой нет. То есть, есть скорее "хранилище данных" в которое все в конце концов отправляется — однако это не совсем база,
т.е. это не сервер баз данных типа sql server — это скорее сайты типа шарепоинта и сервсиы всякие куда инфа складывается.
Но это я думаю не принципиально.
S>Если "чего" — вам точно нужен человек, который проектировал и сопровождал подобные системы на практике.
Здравствуйте, tdiff, Вы писали:
bnk>>4. Использовать некий скриптовый язык, и иметь правила валидации на нем. bnk>>Например использовать как-то Roslyn в виде скрипта. Как это проще сделать и на чем? bnk>>Валидируемые сущности — это по сути обычные объекты. Они должны быть доступны из скрипта.
T>Я скорее за такой вариант. Часто делают скриптовые расширения на луа, питоне. Можно менять валидацию на продакшне, при этом ничего не перезапуская T>С другой стороны, отлаживать встроенные скрипты может оказаться довольно непростым делом.
Спасибо! А как это выглядит на практике? Насколько это общепринятный подход к таким задачам?
Например, можешь плиз кинуть ссылку где сказано как встроить скрипты на Lua или Python в ASP.NET, то есть,
чтобы они имели доступ к обычным .NET объектам.. Насколько это распространенная практика? В Lua же вроде вообще толком нет объектов,
как туда мапить бизнес-объекты и их методы, не станет ли это еще большим геморроем чем просто писать код.
Что-то я с пол-пинка в гугле не смог найти.
Говоря про скрипты я представлял себе что-то типа встроенных скриптов на C# через Rolsyn или что-то типа CSScript.
Но вопрос насколько это сейчас реально/используется.
bnk>В системе есть слой бизнес-логики, и каждый объект должен проходить некую проверку (валидацию). bnk>причем многие проверки являются скорее перекрестными правилами. bnk>1. Писать код. Самый очевидный подход, но не очень гибкий. bnk>2. Построить какой-то свой фреймворк для описания правил и переметризировать правила выше чтением неких конфиг-файлов. bnk>3. Использовать стандартный фремворк для валидации (какой посоветуете?) bnk>4. Использовать некий скриптовый язык, и иметь правила валидации на нем.
Все перечисленное
bnk>В общем, поделитесь опытом плиз. Спасибо!
Стандартного подхода нет. Бизнес-правила будут меняться, меняться много раз, с разной частотой и разными людьми, бизнес-логика тоже будет меняться. В процессе будут выявлены правила, которые почти не меняются, а если и меняются то очень незначительно, их можно закодировать, будут выявлены правила, у которых меняются только параметры, будут выявлены правила, у которых меняются алгоритмы и т.д. и т.п. Для каждого случая удобно применять свой механизм. Обычно на такое уходит года три эксплуатации, и примерно два-три пересмотра архитектуры системы. После чего система может лет 8-10 эксплуатироваться почти без изменений.
bnk>"Если договор заключен до 30 июня, то в приложении к нему (связанный объект) должен присутствовать документ с маркером ABC" bnk>"Если задание было выполнено подразделением X, то в поле Y должна быть подпись Карла и еще в пакете должен присутствовать договор с организацией Z на сумму не менее чем 100 рублей"
А оптимизировать саму бизнес-логику нельзя??
Как правило, сложные условия возникают из-за традиции соединять несколько бизнес операций в одном бумажном документе, в котором изменения (пометки) делают разные службы. Необходимо разбивать такие документы на отдельные простые (универсальные) операции, а пользователю можно показывать, будто это один документ так и остался.
bnk>Я правильно понимаю, ты советуешь по сути 1 вариант — не выпендриваться и писать код? bnk>Кодируя все правила бизнес-логики и валидации. Проблемы деплолймента решать соответствующими методами.
А это от задачи зависит. Вы что хотите получить в итоге? Если нужен простейший вариант — то да, код + стандартный редеплой. Большинство проектов этот вариант устраивает, т.е. нужно для начала определиться, чем он вам не подходит.
Если есть желание написать мегадвижок с скриптами, а поверх него прикрутить БЛ — нет ли смысла вынести скриптовую часть на готовый NodeJs с TypeScript?
Кто будет сопровождать этот код? Если сами разработчики — то зачем тут скрипты?
Если бизнес-аналитики — где вы таких аналитиков найдёте? Не проще будет добавить UI вида стандартного построителя фильтров?
После того, как вы сами себе ответите на эти вопросы, кмк, будет уже понятно, куда конкретно двигаться.
Здравствуйте, bnk, Вы писали:
bnk>Спасибо! А как это выглядит на практике? Насколько это общепринятный подход к таким задачам?
Эти сценарии используются, когда есть большой шанс влипнуть в бизнес-требования, меняющиеся каждый час. Это выглядит как "движок", выполняющий какую-то программу, заданную в скрипте. Этот движок предоставляет интерфейс к бизнес-объектам: создать объект, получить какой-то атрибут, послать объекту сообщение, итп.
bnk>Например, можешь плиз кинуть ссылку где сказано как встроить скрипты на Lua или Python в ASP.NET, то есть, bnk>чтобы они имели доступ к обычным .NET объектам.. Насколько это распространенная практика? В Lua же вроде вообще толком нет объектов, bnk>как туда мапить бизнес-объекты и их методы, не станет ли это еще большим геморроем чем просто писать код. bnk>Что-то я с пол-пинка в гугле не смог найти.
T>Эти сценарии используются, когда есть большой шанс влипнуть в бизнес-требования, меняющиеся каждый час. Это выглядит как "движок", выполняющий какую-то программу, заданную в скрипте. Этот движок предоставляет интерфейс к бизнес-объектам: создать объект, получить какой-то атрибут, послать объекту сообщение, итп.
+1
T>Я никогда не использовал луа совместно с .net, но как-то не верится, что всё так сложно: https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=lua%20c%23
Ну тут два момента: чисто технически прикрутить практически любой распространённый скриптовой язык не проблема — c# script, iron python, nlua, etc. Если не стоит требования совместимости с "нативной" реализацией, чтоб переносить скрипты с другой системы, выбор не ограничен практически ничем.
А вот с прикладной точки зрения всё не так гладко, и надо очень тщательно выбирать и отлаживать связку сайт+движок. Потенциальных проблем куча:
утечки памяти и общая производительность под массовой нагрузкой;
защита от инъекций;
возможность упаковать скрипт в песочницу;
простота языка + возможность отладки
и тыды и тыпы.
Это если не говорить о собственно разработке и сопровождении. Нужно хорошо подумать, будет ли скрипт дешевле в поддержке, чем простенький xml с набором условий, редактируемый через ui-дизайнер. Ну, и наконец, нужен ли он вообще
Здравствуйте, Sinix, Вы писали:
S>Это если не говорить о собственно разработке и сопровождении. Нужно хорошо подумать, будет ли скрипт дешевле в поддержке, чем простенький xml с набором условий, редактируемый через ui-дизайнер. Ну, и наконец, нужен ли он вообще
S>В общем, ждём ответа топикстартера.
Согласен, там куча моментов, которые могут иметь или не иметь значения.
Здравствуйте, tdiff, Вы писали:
T>Здравствуйте, bnk, Вы писали:
bnk>>Спасибо! А как это выглядит на практике? Насколько это общепринятный подход к таким задачам?
T>Эти сценарии используются, когда есть большой шанс влипнуть в бизнес-требования, меняющиеся каждый час. Это выглядит как "движок", выполняющий какую-то программу, заданную в скрипте. Этот движок предоставляет интерфейс к бизнес-объектам: создать объект, получить какой-то атрибут, послать объекту сообщение, итп.
bnk>>Например, можешь плиз кинуть ссылку где сказано как встроить скрипты на Lua или Python в ASP.NET, то есть, bnk>>чтобы они имели доступ к обычным .NET объектам.. Насколько это распространенная практика? В Lua же вроде вообще толком нет объектов, bnk>>как туда мапить бизнес-объекты и их методы, не станет ли это еще большим геморроем чем просто писать код. bnk>>Что-то я с пол-пинка в гугле не смог найти.
T>Я никогда не использовал луа совместно с .net, но как-то не верится, что всё так сложно: https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=lua%20c%23
Ага, спасибо, было как-то не по глазам
Но насколько я вижу, это будет скорее экзотика, потом же эти скрипты на Lua например придется поддерживать обычным смертным. Скорее всего, Lua идет лесом.
Из соображений поддержки, самым простым представляется, чтобы все правила были написаны на том же языке что и все остальное (C#).
Скрипты в буквальном смысле не обязательны; это рассматривалось как опция для "горячей" замены небольших кусочков кода (относящихся к валидации)
Вполне может быть, что это можно сделать и как-то по-другому.
Смысл возиться с правилами в xml файлах видится, если есть уже готовый стандартный фреймворк
от известного производителя с готовым UI для редактирования правил (есть такое?)
Немного деталей по нашей задаче. Правила меняются нечасто (может раз в неделю-месяц). Число одновременных пользователей — единицы-десятки скорее всего, то есть речь об особой какой-то нагрузке не идет.
Что желательно, так это то, чтобы можно было было правила поменять без деплоймента новых сборок на продакшен, еще лучше — как-то из админки.
Здравствуйте, bnk, Вы писали:
bnk>Смысл возиться с правилами в xml файлах видится, если есть уже готовый стандартный фреймворк bnk>от известного производителя с готовым UI для редактирования правил (есть такое?)
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте форумчане.
bnk>Разрабатываем систему на (ASP.NET) bnk>В системе есть слой бизнес-логики, и каждый объект должен проходить некую проверку (валидацию). bnk>причем многие проверки являются скорее перекрестными правилами.
bnk>В общем, поделитесь опытом плиз. Спасибо!
Делюсь: Разберись зачем нужны эти правила, что будет с объектами если правила не выполняются
Когда разберешься станет понятно, что эти правила — не инварианты системы, а предусловия к некоторым операциям
Сделай операции явными. Даже если явной операции нет, то введи в систему операцию "проведения документа" (согласование или чето-там еще)
Для начала можно правила описывать кодом (классы реализующие IBusnessRule)
Если правила действительно часто меняются (а не добавляются по одному за полгода), то можно проверки сделать на WF
Если надо чтобы правила делались людьми, далекими от программирования, то нужен DSL. Желательно не скриптовый язык, а именно DSL, который генерит экземпляры составные объекты IBusinessRule
Здравствуйте, gandjustas, Вы писали:
G>Делюсь
Спасибо за поддержку.
G>Разберись зачем нужны эти правила, что будет с объектами если правила не выполняются
Это известно; мы работаем с пакетами документов, которые проходят утверждение по инстанциям.
Пример выше довольно искусственный для нашего случая, я уже писал об этом выше в ветке.
Я его привел просто чтобы избежать ответов в стиле "используй атрибут Required".. извиняюсь, если ввел в заблуждение.
G>Когда разберешься станет понятно, что эти правила — не инварианты системы, а предусловия к некоторым операциям
Не совсем, у нас, даже если правила не выполняются, операции по-прежнему возможны.
Но несоответствие "правилам" должно быть понятно. То есть, можно думать о чем-то типа "health center", или "dbcc check" для sql сервера.
G>Сделай операции явными. Даже если явной операции нет, то введи в систему операцию "проведения документа" (согласование или чето-там еще)
Операции все и так явные, и, в общем, от данных правил не особо зависят.
Все реальные операции производятся в WF / шарепоинте / прочих сервисах.
Т.е. подразумевается "навесная" валидация/анализ, не влияющая на основной процесс/воркфлоу, она носит скорее "рекомендательный" характер.
Не думаю что это важно, но надеюсь что немного проясняет ситуацию.
G>Для начала можно правила описывать кодом (классы реализующие IBusnessRule) G>Если правила действительно часто меняются (а не добавляются по одному за полгода), то можно проверки сделать на WF G>Если надо чтобы правила делались людьми, далекими от программирования, то нужен DSL. Желательно не скриптовый язык, а именно DSL, который генерит экземпляры составные объекты IBusinessRule
Правила меняются нечасто (выше писал — характерная цифра — неделя).
Про DSL это уже теплее! А какие конкретно DSL для подобной задачи могут подойти? Или предполагается что DSL надо писать самим?
То есть, я наверное скорее заинтересован в обсуждении не общих принципов типа IBusinessRule (хотя тоже интересно), а готовых фреймворков/библиотек...
Здравствуйте, bnk, Вы писали:
bnk>Не совсем, у нас, даже если правила не выполняются, операции по-прежнему возможны.
А зачем тогда проверки?
bnk>Но несоответствие "правилам" должно быть понятно. То есть, можно думать о чем-то типа "health center", или "dbcc check" для sql сервера.
Кому должно? В чем смысл?
bnk>Операции все и так явные, и, в общем, от данных правил не особо зависят. bnk>Все реальные операции производятся в WF / шарепоинте / прочих сервисах.
Если все в шарике, то назначай задачи на выполнение нужных действий. Зачем надо проверять?
bnk>Т.е. подразумевается "навесная" валидация/анализ, не влияющая на основной процесс/воркфлоу, она носит скорее "рекомендательный" характер. bnk>Не думаю что это важно, но надеюсь что немного проясняет ситуацию.
Это очень важно.
Без явной операции как ты сообщишь, что конкретный объект нарушает правила?
Представь что у тебя есть список из тысячи объектов. Как узнать что на 29 странице нарушается правило?
Еще более интересный сценарий — если с новым правилом некоторые старые объекты стали "невалидными", как об этом узнать? А если объектов сотни тысяч?
Тут без конкретного бизнес-сценария невозможно правильное решение придумать.
Здравствуйте, bnk, Вы писали:
bnk>В общем, поделитесь опытом плиз. Спасибо!
Общий дизайн я бы видел так.
Выделить API для работы с документами и оно вряд ли сменится кардинально, т.к. документы и атрибуты документов это бизнес-модель.
Первоначально закодировать необходимые правила для валидации доков. Позже, когда основные правила и варианты использования станут понятными, прорефакторить модель проверки, выделив общие части, создав иерархии и т.д. Возможно появятся валидаторы, правила и т.д. Что-то захардкожено, что-то вынесено в конфиг/скрипт.
bnk>В системе есть слой бизнес-логики, и каждый объект должен проходить некую проверку (валидацию). bnk>причем многие проверки являются скорее перекрестными правилами.
bnk>"Если договор заключен до 30 июня, то в приложении к нему (связанный объект) должен присутствовать документ с маркером ABC" bnk>"Если задание было выполнено подразделением X, то в поле Y должна быть подпись Карла и еще в пакете должен присутствовать договор с организацией Z на сумму не менее чем 100 рублей"
bnk>Не слишком наглядно, но принцип думаю понятен. Правил много (десятки-сотни). bnk>Как обычно реализуется такая логика валидации?
1. Изменение логики валидации практически всегда связано с изменением / дополнением логики заложенных в системе бизнес процессов.
Например, нарушение правила проверки договоров повлечёт за собой запуск компенсирующего бизнес процесса для исправления невалидного состояния договора:
— возврат договора на доработку менеджеру, который в своё время не принёл приложение с маркером АБС, т.к. этот приложение раньше не было нужно
— менеджер дополнит договор в системе приложением с маркером АБС
— а что если ещё и пересогласование договора потребуется?
2. Вынос системы валидации объектов за пределы кода, скорее всего потребует выноса описания бизнес процессов за пределы кода, иначе теряется смысл всей этой затеи.
3. Не проще ли сразу поискать систему, которая позволяет описывать / моделировать бизнес процессы без привлечения программистов?
Не проще будет добавить UI вида стандартного построителя фильтров?
