Где находится бизнес-логика в паттерне MVC? - PullRequest
3 голосов
/ 24 декабря 2010

Я использую Zend Framework и Doctrine.Во многих проектах бизнес-логика встроена в контроллер .Этот подход кажется мне неправильным.

Лучшая установка, которую я когда-либо видел, это использование сервисных уровней , и именно здесь была написана бизнес-логика.Все, что мне нужно было сделать, это создать форму, проверить ее и использовать некоторую бизнес-логику на уровне обслуживания.Проверка результатов, бизнес-логика и работа с одним методом (например, newProduct ($ postData)).

Как правильно организовать мою бизнес-логику в MVC?Может быть, мне нужно прочитать несколько книг или посмотреть примеры исходного кода.

Ответы [ 3 ]

11 голосов
/ 24 декабря 2010

Я не могу говорить за Zend Framework (или за все, над чем вы работаете, которое было построено с его использованием), но в общем случае в паттерне MVC бизнес-логика принадлежит моделям.

YouВозможно, вы уже слышали это заявление о том, что вы должны «держать ваши контроллеры легкими, а ваши модели тяжелыми» (или некоторые их варианты).Идея состоит в том, что Модели - это ваша область (ваш вездесущий язык), и вся бизнес-логика должна быть закодирована в них и в их взаимодействиях.Контроллеры - это просто обработчики событий в MVC, которые получают запросы и переводят их в Модели.

Редактировать: (в ответ на ваш комментарий) - боюсь, у нас возникличто-то вроде языкового барьера здесь.Но, чтобы добавить к сути и, надеюсь, помочь вам в построении модели самостоятельно и данных, являющихся первичными, рассмотрим цитату Эрика Рэймонда: «Умные структуры данных и тупой код работают намного лучше, чем наоборот».

Идея заключается в том, что «логика» заключается в ваших структурах данных, посредством чего вы создаете «богатую» модель предметной области, полную логики и функциональности.Это в отличие от «анемичной» модели предметной области, которая представляет собой просто плоские структуры данных (или DTO), которые представляют собой не что иное, как представление состояния данных и не имеют никакой функциональности.

При использовании интеллектуальных структур данных кодкоторый использует их (которые будут в ваших контроллерах, а также в различных других местах) не должен быть сложным или сложным.Он просто должен сказать моделям, что происходит, и направить их делать то, что им нужно.У моделей есть все ноу-хау, чтобы на самом деле это сделать.

Это предпочтительнее, чем "умный код и глупые структуры данных", где Модели - это анемичные DTO (которые используют, не поймите меня неправильно)и вся логика представлена ​​в более процедурном формате, где каждая процедура должна иметь под рукой все ноу-хау для выполнения бизнес-задачи.Это приводит, помимо прочего, к большому дублированию кода.

Надеюсь, это поможет.Как я уже сказал, мне трудно понять весь объем вашего вопроса.

Редактировать: Еще одна вещь, которую следует учитывать, так как я не уверен, куда вы шли с«данные являются первичной» проблемой.Существует различие между «структурами данных» и «постоянством данных», и это различие абсолютно необходимо.Ваши структуры данных - это ваши модели, обогащенные бизнес-логикой.Ваше постоянство данных - это данные в базе данных.

Очень часто (слишком часто, если вы спрашиваете меня) эти понятия путаются в программировании.В большинстве автоматически сгенерированных кодов и полезных сред, а также во всем этом, «Модели» имеют тенденцию быть прямыми сопоставлениями с таблицами базы данных и просто представлять записи в этих таблицах.Это не всегда неправильно, но вводит в заблуждение.

Бизнес-логика отсутствует в базе данных.Это не в плоском представлении данных.Конечно, база данных может содержать свою собственную логику персистентности (такую ​​как ссылочная целостность, триггеры, аудит, неизвестный коду бизнес-логики и т. Д.), Но она не содержит бизнес-процессов, которые вы обычно видите на потоковой диаграмме.бизнес-логики.

Эти концепции могут выходить из строя для стандартной операционной процедуры любой конкретной структуры.Как я уже сказал, я не могу говорить за рамки.Но лично я склонен защищать «хороший код», а не «популярное использование данного инструмента».

6 голосов
/ 24 декабря 2010

Я приведу некоторые мои мнения о кодировании паттернов MVC. Для ленивых программистов действительно легко испортить коды между контроллерами и моделями.

Ниже была моя структура папок:

  1. Контроллеры: должны быть легкими и чистыми, здесь нужно только определить, какие модели или виды следует загрузить для ответа на запрос.
  2. Просмотров: Даже думал, что он может получить доступ к моделям напрямую, но я предпочитаю делать это через контроллеры. И держите HTML в чистоте.
  3. Модели: все сделано, но разделено на папки.
    • Классы / Объекты: содержит все объекты на основе схемы базы данных.
    • Репозиторий / Фабрика: включает метод запроса, вставки, обновления и удаления. Отображать только один файл в одну таблицу.
    • Службы: бизнес-логика, вход в систему, выход из системы или все, что не связано с базой данных или даже объединяет таблицу и возвращает результаты.
    • Утилиты: Статический метод для представлений, основанный на репозитории / фабрике.

Надеюсь, это поможет! и приветствую любые предложения.

0 голосов
/ 18 декабря 2012

Я скажу, что бизнес-уровень является частью контроллера, поскольку он состоит из всех компонентов, которые позволяют пользователю взаимодействовать как с представлением, так и с моделью. От поиска, обработки, преобразования и даже управления данными приложения и бизнес-правилами.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...