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

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

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

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

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

31 голос | спросил jellyfishtree 14 TueEurope/Moscow2010-12-14T22:30:12+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 22:30:12 +0300 2010, 22:30:12

6 ответов


18

В идеале none

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

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

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

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

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

ответил Josh K 14 TueEurope/Moscow2010-12-14T22:44:41+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 22:44:41 +0300 2010, 22:44:41
9

Как можно меньше. Предпочтительно нет.

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

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

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

ответил Eric King 14 TueEurope/Moscow2010-12-14T22:43:19+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 22:43:19 +0300 2010, 22:43:19
6

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

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

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

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

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

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

ответил Pete 27 Jpm1000000pmThu, 27 Jan 2011 22:42:03 +030011 2011, 22:42:03
4

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

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

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

ответил Nathan Taylor 14 TueEurope/Moscow2010-12-14T22:44:35+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 22:44:35 +0300 2010, 22:44:35
3

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

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

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

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

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

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

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

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

ответил 14 TueEurope/Moscow2010-12-14T23:59:27+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 23:59:27 +0300 2010, 23:59:27
2

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

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

Третьим вариантом будет ссылка на объекты утилиты как отдельный класс утилиты, но это несколько противоречит шаблону, по мнению многих.

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

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

ответил Bill 14 TueEurope/Moscow2010-12-14T23:40:04+03:00Europe/Moscow12bEurope/MoscowTue, 14 Dec 2010 23:40:04 +0300 2010, 23:40:04

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132