Прежде всего, я видел много вопросов об этом, но об этом недостаточно. Если мой вопрос не достаточно хорош и должен быть удален, я пойму. Я рассмотрел, например, этот, и ответ на 45+ проголосовал за ответ, он советует вам поставить бизнес-логику в модель, которая звучит довольно логично.
Однако мой первый большой проект, который я сделал со всеми моими BL полностью в контроллерах, потому что я не задавал эти вопросы и не посмотрел, как это делается в AccountController , который автоматически добавляется, если вы выберете MVC с аутентификация формы. Все методы выглядят довольно набитыми BL.
Или, может быть, это наименьшее количество кода, которое можно было добавить, и я не замечаю ничего? Человек на youtube спросил меня, прав ли он, вложив всю логику в свои модели, и сначала я не был! Тогда я начал думать, что, может быть, он был прав!? Итак, в конце концов, где я могу поместить свою бизнес-логику?
Если это класс моделей, то сколько кода следует считать здоровой суммой в методе, который находится в контроллере? Одна строка для вызова некоторого метода из модели в контроллере больше всего, а затем возврат к представлению?
Веб-приложение на asp.net mvc core — #7 Business Layer: создание уровня бизнес-логики
Andrius Naruševičius 01 сен. 2013, в 23:53
Поделиться
Бизнес логика уходит в контроллеры. Модельная логика идет в Model. Модельная логика — это вещи, которые имеют дело только с моделью. Сеттеры / геттеры / свойства / сумматоры / съемники и т. Д.
crush 01 сен. 2013, в 21:48
ChiefTwoPencils 01 сен. 2013, в 22:14
Andrius Naruševičius 01 сен.
2013, в 22:15
Конечно, это объяснение правильного использования MVC в The Big Nerd Ranch Guide, но, к сожалению, вам придется купить книгу, чтобы подтвердить это.
ChiefTwoPencils 01 сен. 2013, в 22:17
Я скажу, хотя, только что попытавшись подтвердить это в книге на C #, в asp.net бизнес-логика переходит на средний уровень, где верхний уровень — это пользовательский интерфейс, средний — контроллер, а нижний — дБ. Но они не говорят конкретно / явно о MVC. Это происходит от C # для программистов 🙂
ChiefTwoPencils 01 сен. 2013, в 22:24
Я изо всех сил пытаюсь понять, как логические рабочие процессы, такие как платежи, могут работать в модели . Другой вариант бизнес-уровня: blog.diatomenterprises.com/…
KCD 11 май 2016, в 23:27
Кто-нибудь знает какие-нибудь большие примеры приложений, которые помещают бизнес-логику в модели? Все, что я нашел, имеют логику в контроллерах (хотя в любом случае они, как правило, довольно простые примеры приложений)
niico 03 окт. 2016, в 14:21
Показать ещё 5 комментариев
Поделиться:
model-view-controller
business-logic
9 ответов
Лучший ответ
Я предпочитаю поместить логику домена в модель по нескольким причинам.
- Модель не должна иметь в ней никакого кода пользовательского интерфейса и, следовательно, будет легче протестировать. Когда это возможно, мне нравится иметь полностью работоспособную (что означает полную проверку) модель перед написанием любого кода пользовательского интерфейса. Контроллер может доверять тому, что модель делает правильные вещи и просто справляется с проблемами пользовательского интерфейса.
- Если вы помещаете логику домена в контроллер, не так легко делиться между различными приложениями или даже между разными контроллерами.
Ferruccio 01 сен. 2013, в 22:49
Поделиться
Архитектура ПО, MVC и бизнес-логика. Критика Django
Да, мне очень понравился #2 потому что мне было трудно делить между контроллерами сам (пришлось использовать такие методы, как статические)!
Andrius Naruševičius 01 сен. 2013, в 22:13
Mark Walsh 02 сен. 2013, в 16:08
Обратите внимание, что я думаю, что в этом ответе говорится о «моделях предметной области» (часть M классического паттерна MVC), что не относится к «модели» ASP.Net MVC (часть паттерна MVVM).
Alexei Levenkov 16 нояб. 2014, в 21:46
Показать ещё 1 комментарий
Мне нравится сохранять мои модели чистыми. I. Просто со свойствами и без бизнес-логики. Я всегда думаю, что это хорошо, чтобы вводить зависимости в контроллер, и эти зависимости содержат логику, которую я выполняю на своих моделях. Мне нравится придерживаться принципа единой ответственности, где это возможно, и я нахожу, что модели с множеством методов быстро раздуваются.
Там плюсы и минусы для обоих, для ввода многих зависимостей есть накладные расходы, но позволяет тестировать изолированно и упрощает классы, и в итоге у вас будут более компактные контроллеры. Несмотря на мою логику, не существующую на моей модели как членов класса, ее все еще бизнес-логику. Я склонен не иметь бизнес-логику, определенную в контроллере, поскольку насмешливые вещи, такие как Httpcontext, немного кошмарны и ненужны.
Mark Walsh 01 сен. 2013, в 21:56
Поделиться
+1 согласен полностью. Я думал, что я единственный, кому нравится сводить обязанности моделей к минимуму!
Lee 24 фев. 2014, в 22:27
Было бы здорово увидеть несколько небольших фрагментов кода, чтобы понять, что вы делаете. Какое соглашение о присвоении имен вы применяете при внедрении зависимостей?
Luke 25 сен. 2014, в 19:47
Mark Walsh 26 сен. 2014, в 09:44
Так что, если вы не вкладываете свою логику в свои модели или контроллеры — куда вы ее помещаете?
niico 09 март 2017, в 11:58
Я ввел классы обслуживания, которые содержат мою бизнес-логику. Использование всей бизнес-логики в модели нецелесообразно, и ваши модели становятся огромными. Вы также должны затем протестировать свои модели!
Mark Walsh 10 март 2017, в 15:18
Как вы передаете аргументы конструктору контроллера? Разве инициализация контроллера обычно не выполняется за кулисами?
Jeff 04 авг. 2017, в 14:44
Я использую внедрение зависимости.
Mark Walsh 05 авг. 2017, в 23:11
Показать ещё 5 комментариев
Логика бизнес принадлежит к предметной области, и все, что принадлежит предметной области, относится к модели в MVC.
Контроллер должен нести ответственность за передачу данных из модели в представление и из представления обратно в модель. Поэтому контроллер является мостом между тем, с чем взаимодействует пользователь, и тем, как программа моделирует и сохраняет состояние проблемы. сантехника, так сказать.
Ключевым моментом здесь является различие между бизнес-логикой и логикой водопровода. На мой взгляд, то, что делает автогенерированный контроллер учетных записей, в основном касается сантехники, а не бизнес-логики. Имейте в виду, что логика водопровода не обязательно короткая, поэтому вам не нужно вводить искусственные ограничения (например, «количество звонков на контроллере не более» ).
Theodoros Chatzigiannakis 01 сен. 2013, в 22:06
Поделиться
Я согласен со всем этим. Тем не менее, я думаю, что большая путаница возникает из-за того, как структурировать классы в модели, особенно с EF. IE: вы используете частичные классы и строите логику в разных файлах C #? один файл для EF и один файл для логики?
S1r-Lanzelot 04 авг. 2017, в 19:23
Моя команда, перемещенная в 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
Контроллеры должны отвечать за передачу данных между моделью и представлением. Помимо этого не должно быть никакого ненужного кода. Например, если вы регистрируетесь, это должно выполняться на уровне модели, а не на контроллере.
Muneeb Zulfiqar 18 янв. 2016, в 11:17
Поделиться
Похоже, что существует некоторая путаница в этой теме. В большинстве случаев кажется, что люди склонны путать шаблон MVC с архитектурой N-уровня как с какой-либо ситуацией. Реальность такова, что два подхода могут использоваться вместе, но один не зависит от другого, и ни один из них не требуется.
Архитектура N-уровня связана с разделением приложения на несколько уровней. Простым примером является то, что приложение разбивается на уровень представления, уровень бизнес-логики и уровень доступа к данным.
MVC — это шаблон проектирования, относящийся к уровню представления приложения. Полностью можно создать приложение, основанное на подходе MVC, не отделяя логику бизнес-логики и доступа к данным от уровня представления и, таким образом, заканчивая дизайном одного уровня.
Результат, если вы следуете подходу MVC, не разделяя приложение на уровни, заключается в том, что в итоге вы получаете модели, представления и контроллеры, у которых есть биты бизнес-правил и логика доступа к данным, смешанные с остальной логикой,
По определению, в архитектуре N-уровневого уровня уровень представления должен только взаимодействовать с уровнем бизнес-логики, поэтому он должен придерживаться того, что любой из компонентов MVC может взаимодействовать только с уровнем бизнес-логики.
Если вы создаете приложение, которое не связано с презентацией и, следовательно, не является слоем презентации, вам не придется заботиться о шаблоне MVC. Тем не менее, вы очень хорошо можете разделить ваше приложение на несколько уровней и, таким образом, следовать дизайну N-уровня, даже если нет слоя представления.
treefiddy 02 март 2017, в 17:40
Поделиться
Вообще говоря, бизнес-логика не должна находиться ни в одном из игроков 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).
Надеюсь, это поможет кому-то!
ahanusa 10 июнь 2017, в 21:06
Поделиться
В основном нет необходимости повторно использовать логику. Скажем, если я решу использовать ASP.NET Core MVC для Web API, я никогда не захочу использовать эту бизнес-логику в WPF или WinForms. Потому что клиент все равно будет общаться с сервером. Поместить бизнес-логику и особенно логику доступа к базе данных на стороне клиента просто плохо.
Konrad 17 авг. 2018, в 12:05
Чем больше уровней вы добавите, я бы сказал, что это снижает удобство обслуживания и тестируемость. В конце концов, интеграционные тесты имеют большее значение.
Konrad 17 авг. 2018, в 12:07
Bob H 24 апр. 2014, в 20:33
Поделиться
Я также предпочел бы, чтобы модели были чистыми. Контроллеры MVC должны использоваться только для вызовов, а также должны быть чистыми. Таким образом, в зависимости от его повторного использования, чувствительности и актуальности бизнес-логику можно написать в
1.WebApi Controller:. Преимущество использования контроллера webapi заключается в том, что вы можете впоследствии вывести их как службы на другие устройства, чтобы ваш код был повторно использован.
2. BAL/Common commonent: Есть несколько логик, которые имеют конкретное использование и не могут быть показаны как api, могут быть нажаты в этом классе.
3. Репозиторий: Все запросы, связанные с базой данных, добавляются в репозиторий. Может быть общий репозиторий, который будет реализовывать все функции (операции CRUD) или конкретные репозитории для каждой таблицы. В зависимости от выполняемых операций.
Nikitesh Kolpe 23 фев. 2015, в 10:32
Поделиться
Я знаю, что это вопрос о MVC, но я думаю, что пример, который я даю (Web API), будет полезен.
Я разрабатываю свой первый веб-API, и я повторно использую бизнес-логику из других приложений. Чтобы быть конкретным, это происходит из внешней DLL, поэтому мой API используется просто для «обсуждения» с решением SAP, получения запросов от ПО и отправки ответов назад.
Как я могу поместить свою логику (уже реализованную) в контроллер? Мне это не нужно. Мой контроллер будет получать, проверять запросы и составлять ответы для отправки данных.
Я работаю с классами ViewModel, и все, что у них должно быть, это функция сопоставления, просто чтобы прочитать информацию из TransferObjects (которая поступает из внешней DLL) и перевести на ViewModel.
Мне не нравится мое приложение (в данном случае Web API), занимающее бизнес-логику, я думаю, что повторное использование будет потеряно таким образом.
Я рассматриваю свою бизнес-логику как зависимость, которую я вводил в контроллер.
Я сделал много рефакторинга в наследии, чтобы предоставить решение с тестируемым модулем, мне пришлось создать множество интерфейсов и реализовать некоторые шаблоны проектирования в наследии, чтобы обеспечить это решение.
С моей точки зрения, бизнес-уровень должен быть отделен от приложения, желательно в другой библиотеке классов. Таким образом, у вас будет реальная концепция разделения, реализованная в вашем приложении.
Конечно, если ваш CORE (бизнес) ваше приложение (API/WebSite), бизнес-правила будут внедрены в ваши классы MVC. Но в будущем, если вы хотите разработать новое приложение, а некоторые бизнес-правила одинаковы, я уверен, у вас будет много проблем только для поддержки той же логики, реализованной в обоих приложениях.
Источник: overcoder.net
Общие сведения ASP.NET Core MVC
ASP.NET MVC является многофункциональной платформой для создания веб-приложений и API-интерфейсов с помощью структуры проектирования Model-View-Controller.
Шаблон MVC
Структура архитектуры MVC разделяет приложение на три основных группы компонентов: модели, представлении и контроллеры. Это позволяет реализовать принципы разделения задач. Согласно этой структуре запросы пользователей направляются в контроллер, который отвечает за работу с моделью для выполнения действий пользователей и (или) получение результатов запросов. Контроллер выбирает представление для отображения пользователю со всеми необходимыми данными модели.
На следующей схеме показаны три основных компонента и существующие между ними связи.
Такое распределение обязанностей позволяет масштабировать приложение в контексте сложности, так как проще писать код, выполнять отладку и тестирование компонента (модели, представления или контроллера) с одним заданием. Гораздо труднее обновлять, тестировать и отлаживать код, зависимости которого находятся в двух или трех этих областях. Например, логика пользовательского интерфейса, как правило, подвергается изменениям чаще, чем бизнес-логика. Если код представления и бизнес-логика объединены в один объект, содержащий бизнес-логику, объект необходимо изменять при каждом обновлении пользовательского интерфейса. Это часто приводит к возникновению ошибок и необходимости повторно тестировать бизнес-логику после каждого незначительного изменения пользовательского интерфейса.
Представление и контроллер зависят от модели. Однако сама модель не зависит ни от контроллера, ни от представления. Это является одним из ключевых преимуществ разделения. Такое разделение позволяет создавать и тестировать модели независимо от их визуального представления.
Функции модели
Модель в приложении MVC представляет состояние приложения и бизнес-логику или операций, которые должны в нем выполняться. Бизнес-логика должна быть включена в состав модели вместе с логикой реализации для сохранения состояния приложения. Как правило, строго типизированные представления используют типы ViewModel, предназначенные для хранения данных, отображаемых в этом представлении. Контроллер создает и заполняет эти экземпляры ViewModel из модели.
Функции представления
Представления отвечают за представление содержимого через пользовательский интерфейс. Они используют обработчик представленийRazor для внедрения .NET кода в разметку HTML. Представления должны иметь минимальную логику, которая должна быть связана с представлением содержимого. Если есть необходимость выполнять большую часть логики в представлении для отображения данных из сложной модели, рекомендуется воспользоваться компонентом представления, ViewModel или шаблоном представления, позволяющими упростить представление.
Функции контроллера
Контроллеры — это компоненты для управления взаимодействием с пользователем, работы с моделью и выбора представления для отображения. В приложении MVC представление служит только для отображения информации. Обработку введенных данных, формирование ответа и взаимодействие с пользователем обеспечивает контроллер. В структуре MVC контроллер является начальной отправной точкой и отвечает за выбор рабочих типов моделей и отображаемых представлений (именно этим объясняется его название — он контролирует, каким образом приложение отвечает на конкретный запрос).
Контроллеры не должны быть чересчур сложными из-за слишком большого количества обязанностей. Чтобы не перегружать логику контроллера, перенесите бизнес-логику из контроллера в модель предметной области.
Если ваш контроллер часто выполняет одни и те же виды действий, переместите эти действия в фильтры.
ASP.NET Core MVC
ASP.NET Core MVC представляет собой упрощенную, эффективно тестируемую платформу с открытым исходным кодом, оптимизированную для использования с ASP.NET Core.
ASP.NET Core MVC предоставляет основанный на шаблонах способ создания динамических веб-сайтов с четким разделением задач. Она обеспечивает полный контроль разметки, поддерживает согласованную с TDD разработку и использует новейшие веб-стандарты.
Маршрутизация
Платформа ASP.NET Core MVC создана на основе маршрутизации ASP.NET Core — мощного компонента сопоставления URL-адресов, который позволяет создавать приложения с понятными и поддерживающими поиск URL-адресами. Вы можете определять шаблоны именования URL-адресов приложения, эффективно работающие для оптимизации для поисковых систем (SEO) и для создания ссылок, независимо от способа организации файлов на веб-сервере. Вы можете определять маршруты с помощью понятного синтаксиса шаблонов маршрутов, который поддерживает ограничения значений маршрутов, значения по умолчанию и необязательные значения.
Маршрутизация на основе соглашений позволяет глобально определять форматы URL-адресов, которые принимает приложение, и как каждый из этих форматов сопоставляется с определенным методом действия на заданном контроллере. При поступлении входящего запроса модуль маршрутизации выполняет синтаксический анализ URL-адреса и соотносит его с одним из определенных форматов URL-адресов, а затем вызывает метод действия связанного контроллера.
routes.MapRoute(name: «Default», template: «//»);
Маршрутизация атрибутов используется для указания сведений о маршрутизации путем добавления атрибутов, определяющих маршруты приложения, к контроллерам и действиям. Это означает, что определения маршрутов помещаются рядом с контроллером и действием, с которым они связаны.
[Route(«api/[controller]»)] public class ProductsController : Controller < [HttpGet(«»)] public IActionResult GetProduct(int id) < . >>
Привязка модели
ASP.NET Core привязка модели MVC преобразует данные запроса клиента (значения форм, данные маршрута, параметры строки запроса, заголовки HTTP), в объекты, которые может обрабатывать контроллер. В результате логике контроллера не требуется определять данные входящего запроса — данные просто доступны в виде параметров для методов действий.
public async Task Login(LoginViewModel model, string returnUrl = null)
Проверка модели
ASP.NET MVC поддерживает возможность проверки, дополняя модель объекта атрибутами проверки заметок к данным. Атрибуты проверки проверяются на стороне клиента до размещения значений на сервере, а также на сервере перед выполнением действия контроллера.
using System.ComponentModel.DataAnnotations; public class LoginViewModel < [Required] [EmailAddress] public string Email < get; set; >[Required] [DataType(DataType.Password)] public string Password < get; set; >[Display(Name = «Remember me?»)] public bool RememberMe < get; set; >>
public async Task Login(LoginViewModel model, string returnUrl = null) < if (ModelState.IsValid) < // work with the model >// At this point, something failed, redisplay form return View(model); >
Платформа обрабатывает проверку данных запроса на клиенте и на сервере. Логика проверки, указанная в типах модели, добавляется в готовые для просмотра представления в виде ненавязчивых заметок и реализуется в браузере с помощью подключаемого модуля jQuery Validation.
Внедрение зависимостей
ASP.NET Core имеет встроенную поддержку внедрения зависимостей (DI). В ASP.NET MVC Core контроллеры могут запрашивать необходимые служб через свои конструкторы, предоставляя им возможность следовать принципу явных зависимостей.
Фильтры
Фильтры помогают разработчикам решать общие задачи, такие как обработка исключений или авторизация. Фильтры активируют пользовательскую логику предварительной и завершающей обработки для методов действий и могут быть настроены для запуска в определенные моменты в конвейерном выполнении определенного запроса. Фильтры могут применяться к контроллерам или действиям в виде атрибутов (или могут выполняться глобально). В состав платформы входит несколько фильтров (например, Authorize ). [Authorize] является атрибутом, который используется для создания фильтров авторизации MVC.
[Authorize] public class AccountController : Controller
Области
Области позволяют секционировать большое ASP.NET Core веб-приложение MVC на небольшие функциональные группы. Область является структурой MVC внутри приложения.
В проекте MVC логические компоненты, такие как модель, контроллер и представление, находятся в разных папках, и для создания связи между этими компонентами MVC использует соглашения об именовании. Крупное приложение может быть целесообразно разделить на отдельные высокоуровневые области функциональности. Например, приложение электронной коммерции с несколькими бизнес-подразделениями, такими как извлечение, выставление счетов и поиск и т. д. Каждый из этих единиц имеет собственные представления логических компонентов, контроллеры и модели.
Веб-API
Помимо того, что ASP.NET Core MV прекрасно подходит для создания веб-сайтов, эта платформа располагает мощной поддержкой для построения веб-API. Создавайте службы, доступные для широкого круга клиентов, включая браузеры и мобильные устройства.
Платформа включает поддержку согласования содержимого HTTP со встроенной поддержкой форматирования данных в формате JSON или XML. Пишите пользовательские модули форматирования для добавления поддержки собственных форматов.
Используйте функции создания ссылок для поддержки гипермедиа. Легко включайте поддержку общего доступа к ресурсам независимо от источника (CORS) для совместного использования веб-API в нескольких веб-приложениях.
Тестирование
Благодаря используемым интерфейсам и внедрению зависимостей платформа хорошо подходит для модульного тестирования. Кроме того, с помощью таких компонентов, как TestHost и поставщик InMemory для Entity Framework, можно быстро и просто выполнять интеграционные тесты. Узнайте больше о тестировании логики контроллеров.
Razor обработчик представлений
ASP.NET Core представления MVC используют обработчик представленийRazor для отрисовки представлений. Razor— это компактный, экспрессивный и гибкий язык разметки шаблона для определения представлений с помощью внедренного кода C#. Razor используется для динамического создания веб-содержимого на сервере. Серверный код можно полностью комбинировать с содержимым и кодом на стороне клиента.
С помощью обработчика представлений Razor можно определить макеты, частичные представления и заменяемые разделы.
Строго типизированные представления
Razor представления в MVC могут быть строго типизированы на основе модели. Контроллеры передают строго типизированную модель в представления для поддержки в них IntelliSense и проверки типов.
Например, следующее представление отображает модель типа IEnumerable :
Вспомогательные функции тегов
Вспомогательные функции тегов позволяют коду на стороне сервера участвовать в создании и отрисовке HTML-элементов в Razor файлах. Вспомогательные функции тегов используются для определения настраиваемых тегов (например, ) или для изменения поведения существующих тегов (например, ). Вспомогательные функции тегов привязываются к определенным элементам на основе имени элемента и его атрибутов. Они предоставляют преимущества отрисовки на стороне сервера, сохраняя при этом возможности редактирования HTML.
Существует множество встроенных вспомогательных функций тегов для общих задач — например, для создания форм, ссылок, загрузки ресурсов и т. д. Кроме того, огромное количество функций доступно в общедоступных репозиториях GitHub и в качестве пакетов NuGet. Вспомогательные функции тегов разрабатываются на C# и предназначены для HTML-элементов на основе имени элемента, имени атрибута или родительского тега. Например, встроенную функцию LinkTagHelper можно использовать для создания ссылки на действие AccountsController для Login :
С помощью EnvironmentTagHelper можно включать в приложения различные сценарии (например, необработанные или минифицированные) для конкретной среды выполнения (разработки, промежуточной или производственной):
Вспомогательные функции тегов предоставляют удобные для HTML возможности разработки и полнофункциональные среды IntelliSense для создания HTML и Razor разметки. Большинство встроенных вспомогательных функций тегов работают с существующими HTML-элементами и предоставляют для них атрибуты на стороне сервера.
Компоненты представлений
Компоненты представлений позволяют упаковывать логику отрисовки и повторно использовать ее в приложении. Они аналогичны частичным представлениям, но имеют связанную логику.
Совместимая версия
Метод SetCompatibilityVersion позволяет приложению принимать или отклонять потенциально критические изменения в поведении, появившиеся в ASP.NET Core MVC 2.1 или более поздних версий.
Дополнительные ресурсы
- MyTested.AspNetCore.Mvc — библиотека Fluent Testing для ASP.NET Core MVC: строго типизированная библиотека модульного тестирования, предоставляющая текучий интерфейс для тестирования приложений MVC и веб-API. (Не поддерживается и не обслуживается Майкрософт. )
- Компоненты Razor для предварительной визуализации и интеграции ASP.NET Core
- Использование внедрения зависимостей в ASP.NET Core
Источник: learn.microsoft.com
MVC: куда девать бизнес-логику?
Я взглянул, например, на это, и 45+ проголосовал за ответ говорит, что он советует вам поместить бизнес-логику в модель, которая звучит довольно логично.
тем не менее, мой первый большой проект я сделал со всеми моими BL полностью в контроллерах, потому что я не ставил под сомнение эти вещи и посмотрел, как это делается в AccountController который автоматически добавляется, если вы выбираете MVC с проверкой подлинности формы. Все методы выглядят довольно набитыми BL. Или, может быть, это наименьшее количество кода, которое можно было добавить, и я пропускаю вещи?
человек на youtube спросил меня, прав ли он, поставив всю логику в свои модели, и сначала я был нет! Тогда я начал думать, что, возможно, он был прав!?
Итак, в конце концов, где я ставлю свою бизнес-логику? если он находится в классах моделей, то сколько кода следует считать здоровым количеством в методе, который находится в контроллере? Одна строка для вызова некоторого метода из модели в контроллере не более, а затем возврат к представлению?
10 ответов:
- модель не должна иметь кода пользовательского интерфейса в нем и, следовательно, быть проще в тестировании. Когда это возможно, мне нравится иметь полностью работающую (то есть полную тестовую модель) перед написанием любого кода пользовательского интерфейса. Контроллер может доверять тому, что модель делает правильные вещи и просто справляется с проблемами пользовательского интерфейса.
- Если вы поместите логику домена в контроллер, это не так просто разделить между различные приложения, или даже между различными контроллерами.
2014-11-17 05:13:57 Ferruccio
Мне нравится держать мои модели в чистоте, т. е. просто со свойствами и без бизнес-логики. Я всегда думаю, что хорошо вводить зависимости в контроллер, и эти зависимости содержат логику, которую я выполняю на своих моделях. Мне нравится придерживаться принципа единой ответственности, где это возможно, и я нахожу, что модели с тоннами методов очень быстро раздуваются.
Есть плюсы и минусы для обоих, инъекция большого количества зависимостей имеет накладные расходы, но позволяет тестировать изолированно и сохраняет классы просто, и вы будете в конечном итоге иметь более компактных контроллеров. Несмотря на то, что моя логика фактически не существует в моей модели как членов класса, ее все еще бизнес-логика. У меня, как правило, нет бизнес-логики, определенной в контроллере, поскольку насмешливые вещи, такие как Httpcontext, немного кошмарны и ненужны.
2013-09-02 01:02:20 Mark Walsh
The бизнес логика принадлежит к проблемной области и все, что принадлежит к проблемной области идет в модель в MVC.
The контроллер должен отвечать за передачу данных из модели в представление и из представления обратно в модель.
Таким образом, контроллер является мостом между тем, с чем взаимодействует пользователь, и тем, как программа моделирует и сохраняет состояние проблемы. Элемент сантехники, так говорить.
ключевым здесь является различие между бизнес-логикой и логикой сантехники. На мой взгляд, то, что делает Автогенерированный контроллер учетных записей, — это в основном сантехника, а не бизнес-логика. Имейте в виду, что логика сантехники не обязательно короткая, поэтому вам не нужно вводить искусственные ограничения (например, «X количество вызовов не более чем в контроллере»).
2013-09-02 00:52:43 Theodoros Chatzigiannakis
моя команда при переходе на 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
контроллеры должен нести ответственность за передачу данных между модель и вид. Кроме этого в нем не должно быть никакого ненужного кода. Например, если вы входите, это должно быть сделано на уровне модели, а не контроллера.
2016-01-18 11:56:53 Muneeb Zulfiqar
там, кажется, некоторая путаница вокруг этой темы. В основном кажется, что люди склонны путать шаблон MVC с N-уровневой архитектурой как ситуацию или/или. Реальность такова, что эти два подхода могут использоваться вместе, но один не зависит от другого и ни один не требуется.
N-уровневая архитектура связана с разделением приложения на несколько уровней.
Простой пример — это когда приложение разбивается на презентационный слой, бизнес логический уровень и уровень доступа к данным.
MVC-это шаблон проектирования, связанный с уровнем представления приложения.
Полностью возможно разработать приложение, следуя подходу MVC, не отделяя бизнес-логику и логику доступа к данным от уровня представления и, таким образом, в конечном итоге с одноуровневым дизайном.
результат, если вы следуете подходу MVC, не разделяя приложение на уровни, заключается в том, что вы получаете модели, представления и Контроллеры, которые имеют биты бизнес-правил и логики доступа к данным, смешанные с остальной логикой.
по определению, в N-уровневой архитектуре уровень представления должен быть способен взаимодействовать только со слоем бизнес-логики, поэтому он должен содержать, что любой из компонентов MVC может взаимодействовать только со слоем бизнес-логики.
Если вы создаете приложение, которое не включает презентацию и, следовательно, не является слоем презентации, вы не должны придется беспокоиться о шаблоне MVC. Тем не менее, вы очень хорошо можете разделить свое приложение на несколько уровней и, таким образом, следовать N-уровневому дизайну, даже если нет никакого уровня представления.
2017-03-02 21:27:41 treefiddy
2014-04-24 22:20:26 Bob H
вообще говоря, бизнес-логика не должна находиться ни в одном из игроков MVC; она должна быть только потреблено по Вашим действиям контроллера.
Как многие уже упоминали, лучше всего создать библиотеку для размещения бизнес-логики в виде набора клиентских агностических, многоразовых компонентов.
когда это делается таким образом, мы значительно увеличиваем повторное использование, совместимость, масштабируемость и тестируемость с нашим программным обеспечением. Мы также уменьшаем нашу зависимость от некоторых особенностей фреймворка, что облегчает переход на более новые / различные технологии.
абстрагирование нашей бизнес-логики в отдельную сборку (или сборки) хорошо служило нам на протяжении многих лет. Наша бизнес-логика может быть использован практически любой .Чистая технология (ASP.NET в MVC, API или ядро, в WPF, выиграть форм, ФОС, магазина, ВФ, консоли и т. д.).
кроме того, нам нравится наш средний уровень для обработки бизнес-правил и логики проверки, чтобы уменьшить наши зависимости от .NET MVC Framework. For например, мы избегаем использования помощников проверки .NET MVCs и вместо этого полагаемся на свои собственные. Это еще один фактор, который позволяет нам легко использовать нашу бизнес-логику из любой технологии .NET.
логическое проектирование нашего среднего уровня таким образом позволило нам легко достичь этой физической архитектуры:
Это было написано с Peasy.NET, и служил нам хорошо на протяжении многих лет. Так хорошо на самом деле, что мы решили с открытым исходным кодом.
Если кому-то интересно, как выглядит наш средний уровень, вот пример клиент-агностик, бизнес-уровень. Он также демонстрирует потребление его несколькими клиентами .NET (ASP.NET MVC, Web Api и WPF).
надеюсь, это кому-то поможет!
2017-10-28 15:23:17 ahanusa
Я также предпочел бы держать модели в чистоте. Контроллеры MVC должны использоваться только для совершения вызовов, а также должны содержаться в чистоте. Таким образом, в зависимости от его многократного использования, чувствительности и релевантности бизнес-логика может быть записана в
1.Контроллер Веб-API: преимущество использования контроллера webapi заключается в том, что вы можете предоставить их в качестве служб позже другим устройствам, что делает ваш код повторно используемым.
2. Бал / общий commonent: есть некоторые логики, которые имеют конкретное использование и не могут быть представлены как api, могут быть выдвинуты в этом классе.
3. Репозиторий: все запросы, связанные с базой данных, добавляются в репозиторий. Может быть общий репозиторий, который будет реализовывать все функции (операции CRUD)или конкретные репозитории для каждой таблицы. В зависимости от выполняемых операций.
2015-02-23 10:34:24 Nikitesh
Как писал ахануса, вы должны поместить свою бизнес-логику в отдельную DLL или отдельный каталог.
Я часто использую каталог с именем Logics на том же уровне моделей и контроллеров, где я помещаю классы, которые делают бизнес-логику.
Таким образом, я позволяю чистить как модели, так и контроллеры.
2018-09-23 13:40:43 Ryozzo
Я знаю, что это вопрос о MVC, но я думаю, что пример, который я даю (Web API), будет полезен.
Я разрабатываю свой первый веб-API, и я повторно использую бизнес-логику из других приложений. Чтобы быть конкретным, он исходит из внешней DLL, поэтому мой API используется только для «разговора» с решением SAP, получения запросов от PO и отправки ответов обратно.
Как я могу поместить свою логику (уже реализованную) в мой контроллер? Мне это не нужно. Мой контроллер будет только получать, проверять запросы и составлять ответы для отправки данных обратно.
Я работаю с классами ViewModel, и все, что они должны иметь, это функция отображения, просто для чтения информации из TransferObjects (которая поступает из внешней DLL) и перевода в ViewModel.
Мне не нравится мое приложение (в данном случае Web API), содержащее бизнес-логику, я думаю, что повторное использование будет потеряно таким образом.
Я рассматриваю свою бизнес-логику как зависимость, которую я вводил в контроллер.
Я сделал много рефакторинга в наследии, чтобы обеспечить модульное тестируемое решение, мне пришлось создать много интерфейсов и реализовать некоторые шаблоны проектирования в наследии, чтобы обеспечить это решение.
на мой взгляд, должен быть кроме заявления, предпочтительно в другой библиотеке классов. Таким образом, у вас будет реальная концепция разделения, реализованная в вашем приложении.
конечно, если ваше ядро (бизнес) это ваше приложение (API / сайт), бизнес-правила будут реализованы в ваших классах MVC. Но в будущем, если вы хотите разработать новое приложение и некоторые бизнес-правила одинаковы, я уверен, что у вас будет много проблем, чтобы поддерживать ту же логику, реализованную в обоих приложениях.
Источник: codengineering.net
