Представлення правил бізнесу за винятком

Я знаю, що це дорого, але (IMO) я вважаю, що це дуже хороша практика. Я говорю про правила, як-от скажімо, ви не можете зберегти рахунок-фактуру, якщо ви не продавець ... тому в такому випадку викидайте виняток із запитом "ваш не має права" або таке ...

Інший підхід - це мати об'єкти зі статусом чи щось подібне

Чи є якийсь інший підхід? як ви ставитесь до цього?

Якщо ви маєте на увазі представлення індивідуальних перевірок правил бізнесу за винятком, то я не думаю, що це дуже гарна ідея. Багато разів доводиться повідомляти про більше ніж одну невдалу умову, а не зупинятися на першій.

З іншого боку, я вважаю, що перевірка дотримання всіх правил, а потім викидання виключень із резюме є хорошою практикою.

У прикладі, який ви нам дали, я думаю, що збільшити виняток - це погана ідея. Якщо ви знаєте, що користувач не має авторизації до того, як він почне працювати, і ви все-таки дозволяєте їм виконувати якусь функцію, а потім присмачуйте їх повідомленням ПОСЛІ, коли вони вже виконали завдання, це просто погана конструкція.

Використання винятків для забезпечення ділових правил не є гарною конструкцією.

Я не бачу, яке значення має виняток у створенні хорошої бізнес-логіки. Існує десятки підходів до управління діловою логікою, які не передбачають використання системи, яка призначена для вирішення несподіваних умов в роботі системи.

Він очікував , що в бізнес - логіці, не будуть виконані умови; це причина того, що це в першу чергу, і ви не хочете, щоб виправити той самий механізм, який обробляє несподівані збої вводу / виводу, від помилок пам'яті та нульових посилань. Це збої в системі, але виявлення незадовільних умов ведення бізнесу є успішною роботою системи.

Крім того, це система, яка дозріла до ненавмисних наслідків. Оскільки в якийсь момент потрібно вилучити виняток, ви ризикуєте виникненням нового винятку з бізнес-правила, коли його не зафіксують, що це не призначено, або ви, можливо, матимете код, який шукає бізнес-правил, виловлюючи винятки, які насправді не мають на увазі для нього. Так, ці умови можна пояснити хорошими методами кодування, але в будь-якій нетривіальній системі, над якою працює більше одного розробника, трапляються помилки, і ви просто повинні сподіватися, що вони не будуть дорогими помилками.

вираження ділових правил - це одне, а їх реалізація - інше

подумайте про досвід користувача; якщо користувач не продавець, тому дати їм кнопку з написом «Створити рахунок» взагалі ?

Це повністю залежить від того, що робиться.

По-перше, якої фактичної поведінки ви хочете? Якщо хтось вводить власну інформацію, то, мабуть, є правильним відхилення та діалогове вікно, яке, по суті, "Ви не можете цього зробити". Якщо це особа, яка вводить дані, працює з купою форм, діалогове вікно, ймовірно, також добре, і людина, що вводить дані, може помістити недійсні форми в спеціальну купу. Якщо ви робите пакетну обробку, ви не хочете припиняти роботу, але позначте її та перейдіть до наступної.

Отримавши поведінку, вам потрібно вирішити, як ви її будете реалізовувати. Мабуть, перевірка ділових правил, яка кидає виняток, - мабуть, хороша ідея. Повернення коду повернення та його передача - це ще щось, що може піти не так, і ви, звичайно, не хочете, щоб помилкові записи продовжувались.

Не турбуйтеся про витрати на продуктивність. У випадку, коли людина вводить дані, це тривіально порівняно з іншими періодами. Зазвичай, людина буде забирати в цій системі найбільше часу. У випадку пакетної роботи, якщо винятки є проблемою продуктивності, ви вводите занадто багато поганих записів, а насправді обробка та повторне введення всіх цих проблем буде більше проблемою, ніж винятками.

Маючи надійний і добре розроблений API винятків, який є послідовним, дуже доречно. Використання цього для забезпечення ділових правил також може бути доречним. Насправді, на мій досвід, чим складніше правило бізнесу, тим більша ймовірність, що воно в кінцевому підсумку буде керовано таким чином. Часто так само просто, якщо не простіше написати систему, де очікуються винятки, ніж написати авторитетну логіку розгалуження.

Це означає, що прості правила, які можна описати в одному реченні, як правило, слід застосовувати запобіжним або авторитетним чином, залежно від того, що це є. Однак якщо у вас є правило, яке є багатовимірним і вимагає більше трьох-чотирьох факторів (особливо якщо вибір цих факторів ґрунтується на одному або декількох інших факторах), то кодування винятків може бути більш ретельним. Часто в цих випадках логічний шлях матиме чимало винятків-попередників, які потрібно кинути, (перевіряє, чому дія не може бути виконана), тоді (або навпаки) відбувається падіння безпеки (щоб перевірити, чи дійство дії дозволено ), іноді буде якась авторитетна логіка накопичення, яку потрібно перевірити (наявність нащадків / предків, попередник повідомляє, що об’єкти потрібно поставити тощо).

Однією з переваг, яка випливає з цього виду викидів винятків, є те, що вона дозволяє відокремлювати та використовувати повторно винятки попередників у кількох областях проекту. (Це суть орієнтованого на аспекти програмування.) Роблячи це, ви інкапсулюєте один конкретний аспект ваших загальних правил бізнесу в самостійний та підтримуваний компонент. Загалом ці компоненти відповідають 1-1 із викинутими повідомленнями про помилки. (Хоча іноді у вас буде один компонент, який викидає кілька різних винятків, майже ніколи не слід мати однаковий виняток, викинутий з кількох компонентів.)

На мою думку, складніше проектувати системи, які базуються на винятках, і початковий час розробки довший, оскільки вам доведеться будувати процес виключення на всіх N рівнях. Однак ці системи, як правило, набагато стабільніші. Хоча ніколи не можливо спроектувати систему, яка "не вийде з ладу", користь дизайну, заснованого на винятках, полягає в тому, що ви завжди очікуєте невдачі. Для більшості людей процес може бути контрінтуїтивним. Це як би просити вказівок і змусити когось сказати вам усі вулиці, які не слід включати.