MVC: Где поставить бизнес-логику?

Прежде всего, я видел много вопросов об этом, но об этом недостаточно. Если мой вопрос не достаточно хорош и должен быть удален, я пойму.

Я рассмотрел, например, этот, и ответ на 45+ проголосовал за ответ, он советует вам поставить бизнес-логику в модель, которая звучит довольно логично.

Однако мой первый большой проект, который я сделал со всеми моими BL полностью в контроллерах, потому что я не задавал эти вопросы и не посмотрел, как это делается в AccountController, который автоматически добавляется, если вы выберете MVC с аутентификация формы. Все методы выглядят довольно набитыми BL. Или, может быть, это наименьшее количество кода, которое можно было добавить, и я не замечаю ничего?

Человек на youtube спросил меня, прав ли он, вложив всю логику в свои модели, и сначала я не был! Тогда я начал думать, что, может быть, он был прав!?

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

Ответ 1

Я предпочитаю поместить логику домена в модель по нескольким причинам.

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

Ответ 2

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

Ответ 3

Логика бизнес принадлежит к предметной области, и все, что принадлежит предметной области, относится к модели в MVC.

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

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

Ответ 4

Моя команда, перемещенная в mvc из webforms (asp.net), сделала много исследований и придумала следующую структуру. По его словам, это не о том, насколько велика или маловата приложение. Его о том, чтобы код был чистым и понятным.

DALProject

AccountsDAL.cs --- > Calls SP or any ORM if ur using any

BLLProject

AccountsBLL.cs ---> Calls DAL

WebProject

Model
    AccountsModel --- > Contains properties And call BLL
Controllers
    IndexController ---> Calls Models and returns View
Views
    Index

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

Ответ 5

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

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

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

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

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

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

Ответ 6

Вообще говоря, бизнес-логика не должна находиться ни в одном из игроков MVC; его следует использовать только для действий вашего контроллера.

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

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

Отсчет нашей бизнес-логики на самостоятельную сборку (или сборку) послужил нам на протяжении многих лет. Теперь наша бизнес-логика может быть использована практически любой технологией .NET(ASP.NET MVC/API/Core, WPF, Win Forms, WCF, UWP, WF, Console и т.д.).

Кроме того, нам нравится наш средний уровень для обработки бизнес-правил и логики проверки, чтобы уменьшить наши зависимости от .NET MVC Framework. Например, мы избегаем использования помощников проверки подлинности .NET MVC и вместо этого полагаемся на свои собственные. Это еще один фактор, который позволяет нам легко потреблять нашу бизнес-логику из любой технологии .NET.

Логическое проектирование нашего среднего уровня таким образом позволило нам легко достичь этой физической архитектуры:

Это было написано с Peasy.NET и с годами служило нам. Так хорошо, что мы решили открыть исходный код.

Если кому-то интересно, как выглядит наш средний уровень, вот sample клиентского агностика, бизнес-уровня. Он также демонстрирует потребление его несколькими клиентами .NET(ASP.NET MVC, Web Api и WPF).

Надеюсь, это поможет кому-то!

Ответ 7

Мне нравится держать мои модели в чистоте (ref: @Mark Walsh). Проблема неспособности повторного использования логики, встроенной в контроллеры, может быть легко преодолена посредством инъекции зависимостей или, если вы считаете, что этого будет слишком много, вы можете разоблачить свою логику бизнеса/домена через интерфейсы и использовать шаблон фасада в контроллерах. Таким образом, вы получаете необходимую функциональность, но держите оба контроллера и модель красивой и чистой.

Ответ 8

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

1.WebApi Controller:. Преимущество использования контроллера webapi заключается в том, что вы можете впоследствии вывести их как службы на другие устройства, чтобы ваш код был повторно использован.

2. BAL/Common commonent: Есть несколько логик, которые имеют конкретное использование и не могут быть показаны как api, могут быть нажаты в этом классе.

3. Репозиторий: Все запросы, связанные с базой данных, добавляются в репозиторий. Может быть общий репозиторий, который будет реализовывать все функции (операции CRUD) или конкретные репозитории для каждой таблицы. В зависимости от выполняемых операций.

Ответ 9

Как писал Ахануса, вы должны поместить свою бизнес-логику в отдельную DLL или отдельный каталог.
Я часто использую каталог с именем Logics на одном уровне с моделями и контроллерами, куда я помещаю классы, которые занимаются бизнес-логикой.
Таким образом, я позволил очистить как модели, так и контроллеры.

Ответ 10

Общий ответ, который у меня есть, заключается в том, что бизнес-логика обычно подразделяется на две категории:

Объектно-ориентированная бизнес-логика: Получает моделирование как объекты (в модели), обычно внедряемые как хранилища.

Процедурная бизнес-логика: входит в службу с интерфейсом, который может быть введен в контроллер.

Логика контроллера: Логика, которая контролирует, как команды принимаются и передаются моделям/сервисам, а затем как эти результаты передаются в представление.

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

Ответ 11

Бизнес-логика не должна входить в ваши представления моделей или контроллеры. Должен быть отдельный уровень бизнес-логики; единственная цель этого слоя - управлять вашей бизнес-логикой. Это больше соответствует SOLID.

Если вы поместите свою бизнес-логику в M V или C, вы получите код, который сложно протестировать/использовать повторно.

Ответ 12

Я знаю, что это вопрос о MVC, но я думаю, что пример, который я даю (Web API), будет полезен.

Я разрабатываю свой первый веб-API, и я повторно использую бизнес-логику из других приложений. Чтобы быть конкретным, это происходит из внешней DLL, поэтому мой API используется просто для "обсуждения" с решением SAP, получения запросов от ПО и отправки ответов назад.

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

Я работаю с классами ViewModel, и все, что у них должно быть, это функция сопоставления, просто чтобы прочитать информацию из TransferObjects (которая поступает из внешней DLL) и перевести на ViewModel.

Мне не нравится мое приложение (в данном случае Web API), занимающее бизнес-логику, я думаю, что повторное использование будет потеряно таким образом.

Я рассматриваю свою бизнес-логику как зависимость, которую я вводил в контроллер.

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

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

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