Сколько бизнес-логики должно существовать на уровне контроллера?

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

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

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

У меня вопрос, сколько бизнес-логики должно быть разрешено в контроллере и при каких обстоятельствах, если таковые имеются?

В идеале нет

Но это не всегда возможно. Я не могу дать вам точные цифры, такие как 20% или 10 строк, это субъективно в том смысле, что на него нельзя ответить. Я могу описать, как я использую шаблоны проектирования и обстоятельства, которые требуют их легкого сгибания.

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

Построение отдельных систем является целью. Если вы начнете писать бизнес-логику, специфичную для взаимодействия двух систем, это проблема. Не глядя дальше, я не могу высказать свое мнение.

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

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

Как можно меньше. Желательно нет.

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

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

Если у вас есть функциональность, которая берет доменные объекты и создает из них видовые модели, то это может разумно сосуществовать с контроллером. Но это должен быть код, который существует только ради соответствующих представлений. Если существует правило бизнес-уровня о санации данных, оно должно существовать в вашем домене / уровне обслуживания (с соответствующими тестами модулей).

Термин «бизнес-логика» часто вводит в заблуждение, потому что у людей разные мнения о том, что это значит. На мой взгляд, термин «бизнес-логика» охватывает две области

• Доменная логика
• Логика приложения

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

Логика приложения - это логика, связанная с тем, что вы запускаете компьютерную программу. Это могут быть такие вещи, как экспорт CSV-импорта, мастера и т. Д. Также могут содержаться такие вещи, как создание электронных писем с забытым паролем.

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

Вы говорили о логике для форматирования или очистки данных. Форматирование должно определенно быть логикой приложения. С другой стороны, очистка может быть доменной логикой, если очистка данных основана на правилах домена. Это зависит от контекста.

Контроллеры должны быть очень легкими в доменной логике.

Контроллеры должны делегировать задачи, такие как извлечение записи из хранилища данных посредством абстрактного уровня службы / хранилища и передача данных обратно в хранилище данных той же (или связанной) службой. Что касается механики и более тонкой работы между этими операциями, обычно они принадлежат где-то, кроме контроллера.

Я часто добавляю в свои контроллеры методы очистки небольших данных, которые сохраняют данные обратно в хранилище, и, хотя это эффективное решение, оно не совсем соответствует предполагаемой роли контроллера. В идеале все, что будет модифицировать, проверять или анализировать вашу модель, должно происходить очень близко, если не в самой модели. Например, если вам необходимо «очистить» объект модели перед его сохранением, рассмотрите возможность использования метода SanitizeInputs () на модели или в качестве части службы, которая обрабатывает хранение модели.

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

Вы можете пойти любым путем, но я обычно пытаюсь подумать, может ли странный бит обнаружиться в более чем одном действии контроллера, если так и происходит в модели. Если это неясно, я пытаюсь подумать, является ли это более «подходящим» в одном месте, чем в другом. В противном случае я обычно помещаю это в модель, просто чтобы держать его вне контроллера (личное предпочтение меньшим контроллерам и более сильным объектам данных, YMMV)

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

Кроме того, просто потому, что вы не строго следуете шаблону, вы не обязательно заигрываете с катастрофой. Если вы действительно не ожидаете значительного количества повторного использования кода в этом проекте, я бы гораздо больше беспокоился о совместимости проекта с самим собой (т. Е. Не вставляйте эти биты, когда вы выбираете местоположение) чем переписать, что по какой-то причине хочет сохранить часть середины проекта. Документируйте / комментируйте, где и почему вы отклонились от общего шаблона, и определите ожидаемый шаблон для этого приложения.

MVC был отклонением от установленных моделей в одной точке.

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

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

Тем не менее, как и многие другие концепции программирования, MVS - это просто упрощение реальности. Это не идеально и не тщательно. Вот почему невозможно вписать сценарий реального мира в упрощенную модель. Отсюда возникает много вопросов, похожих на этот.

• Сколько логики должно идти в контроллер?

• Должен ли вид содержать какую-либо условную логику?

• Должна ли модель содержать какие-либо дополнительные данные, не найденные непосредственно в бизнес-объектах?

Все эти вопросы возникли в попытке изменить код так, чтобы он точно и полностью соответствовал концептуальной идее MVC.

Мой ответ тебе не пытайся. MVC обеспечивает структуру. Создайте свое приложение на этом фундаменте, но не ожидайте, что оно идеально подойдет. Будут отклонения, это нормально. Просто смотрите, чтобы держать их под контролем.