Скільки логіки бізнесу має бути дозволено існувати в рівні контролера?

Іноді у коді контролера наших додатків представлена ​​деяка логіка бізнесу. Зазвичай це логіка, яка відрізняє методи виклику від моделі та / або які аргументи для їх передачі.

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

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

Моє запитання - скільки ділової логіки має бути дозволено в контролері та за яких обставин, якщо вони є?

В ідеалі немає

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

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

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

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

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

Якнайменше. Переважно жодного.

Контролер повинен перейматися прийняттям запиту, проханням правильної служби домену обробити запит і передачею відповіді на правильний вигляд.

У цьому процесі в доменних службах повинна існувати вся "бізнес-логіка".

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

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

• Логіка домену
• Логіка застосування

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

Логіка програми - це логіка, пов'язана з тим, що ви запускаєте комп'ютерну програму. Це можуть бути такі речі, як експорт імпорту CSV, майстри тощо. Можуть містити також такі речі, як створення забутих електронних листів із паролем.

"Логіка бізнесу", яку ви можете розмістити в шарі контролера, - це логіка програми. Можливо, не вся логіка додатків повинна йти туди. Але ніколи не слід розміщувати логіку домену в шарі контролера. Це, очевидно, має бути в доменному шарі.

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

Контролери повинні бути дуже легкими щодо логіки домену.

Контролерам слід делегувати такі завдання, як отримання запису із сховища даних за допомогою абстрагованого рівня обслуговування / репозиторію та передачі даних назад у сховище даних тією ж (або пов’язаною з ним) службою. Що стосується механіки і тонкої роботи між цими операціями, зазвичай вони належать десь, крім контролера.

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

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

Ви можете піти в будь-який бік, але я зазвичай намагаюся подумати, чи дивний біт, ймовірно, відображатиметься в більш ніж одній дії контролера, якщо це так і в моделі. Якщо це незрозуміло, я намагаюся подумати, чи більше воно «підходить» в одне місце, ніж в інше. Якщо я зазвичай не розміщую його в моделі просто для того, щоб не мати контролера (особисті переваги менших контролерів і більш сильних об'єктів даних, YMMV)

Третім варіантом буде посилання на елементи корисності як окремий клас корисності, але це дещо суперечить зразкам, як на думку багатьох.

Крім того, тільки тому, що ви не суворо дотримуєтесь такої схеми, ви не обов'язково заграєте з катастрофою. Якщо ви дійсно не очікуєте значної кількості повторного використання коду від цього проекту, я б потурбувався набагато більше за те, щоб проект був узгоджений із собою (тобто: не перекладайте туди, куди ви кладете ці біти, як тільки ви виберете місцеположення) ніж переписати, що чомусь хоче зберегти частину середини проекту. Документуйте / коментуйте, де і чому ви відхилилися від загальної моделі та визначте очікувану схему для цієї програми.

MVC було відхиленням від встановлених самих моделей в одній точці.

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

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

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

• Скільки логіки повинно входити в контролер?

• Чи має подання містити якусь умовну логіку?

• Чи повинна модель містити додаткові дані, які не знайдені безпосередньо у суб’єктів господарювання?

Це все питання, що виникають у спробі коригування коду, щоб точно і повністю відповідати концептуальній ідеї MVC.

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