Товсті моделі, худі контролери та модель дизайну MVC


75

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

  • Товсті моделі, худі контролери
  • Зберігайте якомога більше ділової логіки в моделях

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

Скануючи свої контролери, я тепер можу визначити багато логіки, яка, ймовірно, повинна йти в моделі:

  • Додаток має списки, які містять елементи, і елементи можна класифікувати. Логіка сортування, яка розміщує список у ранговому порядку, знаходиться в контролері.
  • Подібно до елементів (модель товару) також є зображення (модель зображення). Кожен елемент може мати зображення за замовчуванням (позначене image_id у таблиці елементів). Коли елемент відображається із його зображеннями, зображення за замовчуванням має з’являтися першим. У мене є логіка, яка робить це в контролері.
  • Коли відображається список, відповідні списки відображаються на бічній панелі. Логіка визначення списків, пов’язаних між собою, знаходиться в контролері.

Тепер до моїх запитань:

  1. З наведеними вище прикладами, чи я на правильному шляху, думаючи, що це екземпляри логіки в даний час у контролері, який належить до моделі?
  2. Які деякі інші логічні сфери, загальні для веб-програм, повинні входити в моделі?
  3. Я впевнений, що виявлення цієї проблеми та зміна дизайну - це половина успіху, але навіть якщо я вирішу взяти ті приклади, які я наводив вище, і спробувати перенести цю логіку на модель, я б не знав, з чого почати. Хто-небудь може направити мене у правильному напрямку, розмістивши тут якийсь код або посилаючись на якісні навчальні ресурси? Допомога у CakePHP була б чудовою, але я впевнений, що всього MVC буде достатньо.

Чув про все це раніше :)
MeTitus

Відповіді:


55

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

Принаймні з точки зору CakePHP:

  1. Так

  2. Все, що стосується даних або обробки даних, повинно бути в моделі. Що стосується CakePHP, як щодо простого методу find ()? ... Якщо існує ймовірність того, що він зробить щось «особливе» (тобто згадує певний набір «умова»), який вам може знадобитися в іншому місці, це хороший привід, щоб загорнути всередину метод моделі.

  3. На жаль, простої відповіді ніколи не буває, і рефакторинг коду є природним процесом. Іноді ви просто прокидаєтеся: "священні макарони ... які повинні бути в моделі!" (ну, можливо, ти цього не робиш, але я це роблю :))


5
Автор блогу пише переможну відповідь FTW!
Xeoncross

19

Я використовую принаймні ці два "тести", щоб перевірити, чи правильна моя логіка:

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

2) Задайте собі питання: а що, якби я додав інший спосіб використання цих класів, чи потрібно було б дублювати функціональні можливості таким чином, що майже копіювати-вставляти? ... Це також, мабуть, вагома причина для переміщення цієї функціональності.

також цікаво: http://www.martinfowler.com/bliki/AnemicDomainModel.html

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.