Куда уходит мой код?Контроллер, Сервис или Модель?

Question

Итак, у нас есть приложение PHP + Zend Framework + Doctrine 1.2, которое имеет следующую структуру:

Контроллер -> Действие -> Сервис -> Модель

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

Мой вопрос: если у вас есть часть бизнес-логики, какие рекомендации вы используете, чтобы определить, должен ли код, реализующий эту логику, находиться на уровне модели, контроллера или сервиса? Меня особенно интересуют различия между уровнем контроллера и сервиса.

Вот рекомендации, которые разработала наша команда разработчиков, но мне очень интересны любые отзывы / отзывы о них:

1. Сервисы и контроллеры содержат логика связывания различных компонентов вместе, чтобы выполнить задачу. Эта логика не может быть в модель, чтобы избежать зависимостей и сделать модель более многоразовая. это логика также не может быть в модели потому что мы думаем, что модель должна избегать потребления вещей до стек приложений, чтобы избежать ненужные зависимости (например: модель не будет потреблять услугу или контроллер).
2. Используйте сервис, а не контроллер, когда код может быть использован несколькими модулями или контроллерами.
3. Модель должна содержать как можно больше логики, но избегать ссылка на конкретное приложение функциональность. Обычно модель содержит хотя бы логику проверки.
4. Для любой функциональности рассмотрите возможность размещения ее в модели. первый. Если есть убедительные причина не рассматривать услугу (также рассмотрите накладные расходы и цель для поддержания нового сервиса). Если услуга не желательна и код не будет повторно использоваться в этом приложение использует контроллер.

Answer 1

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

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

При оптимизации для каждого экземпляра вы перемещаете код в место, где он оптимален для производительности, но на первой итерации я все равно размещаю его на уровне обслуживания.

Я согласен, что модели должны содержать как можно больше логики внутренней фокусировки, но модель должна быть неспецифичной. Бизнес-логика - это сценарий использования, который использует модель для вашего приложения, поэтому должен быть отдельным.

Answer 2

В вашем контексте я бы рассматривал модели и контроллеры как части бизнес-логики; модели, определяющие, «что» является вещами, контроллеры, определяющие, «как» к ним обращаются.

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

Сервисы и контроллеры содержат логику для связывания различных компонентов выполнить задачу.

Да, я также согласен с вашим утверждением об избежании зависимости и т. Д. Модель не должна зависеть ни от чего, кроме других тесно связанных моделей ( Общий принцип закрытия ).

Кроме того, если логика специфична для модели - тогда она должна идти; если логика более общая, ее следует разместить на уровне оценки - возможно, контроллера или общей внутренней утилиты.

Используйте сервис, а не контроллер когда код может использоваться несколькими модули или контроллеры.

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

Модель должна содержать как можно больше логики насколько это возможно, но избегайте ссылок функциональность для конкретного приложения. Обычно модель содержит как минимум логика проверки.

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

Для любой функциональности рассмотреть возможность размещения его в модели первый. Если есть веская причина не рассматривать услугу (также рассмотреть накладные расходы и цель для поддерживать новый сервис). Если услуга не желательно, и код не будет повторно использовать в этом приложении использовать контроллер. * 1 028 *

это зависит от того, что это за «функция», если она специфична для модели, то, вероятно, она принадлежит модели; если он является общим для нескольких моделей, то он либо принадлежит контроллеру, либо общему служебному классу в бизнес-логике.

Когда я начал писать все это, я хотел сосредоточиться на определении используемых вами терминов; Я все равно решил включить это - так что поправьте меня, если я ошибаюсь :) И, как вы можете видеть, мне не ясно, что вы подразумеваете под "действием" в вашем контексте.

• Модель: ( из Википедии - MVC ) «Модель используется для управления информацией и уведомления наблюдателей, когда эта информация изменяется; это также доменное представление данных, на которых работает приложение». На мой взгляд, это подразумевает свойства и тому подобное, а не методы.
• Контроллер: ( из Википедии - MVC ) "Получает ввод и инициирует ответ, совершая вызовы на объектах модели. Контроллер принимает входные данные от пользователя и инструктирует модель и область просмотра выполнять действия, основанные на этом вход. "
• Сервис: существует множество разных мнений о том, что такое сервис, я полагаю, в вашем контексте это сервис: внешняя вызываемая точка (в контексте уровней вашей системы), которая дает конкретный ответ на конкретный вопрос , (Услуги обычно основаны на бизнес-концепциях, а не технических.)
• Действие: Я не знаю, что вы явно подразумеваете под этим.