Бизнес-уровень или нет в MVC?

Question

Когда удобно иметь бизнес-уровень в веб-приложении mvc?Почему вызовы из контроллера идут прямо на уровень доступа к данным?

Answer 1

когда удобно иметь бизнес-уровень в вашем веб-приложении mvc?

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

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

Почему звонки с контроллера прямо на уровень доступа к данным?

Не знаю, это было бы плохой практикой ИМХО, поскольку это сделало бы ваши контроллеры тесно связанными с вашей базой данных и, как следствие, сложным для модульного тестирования.Что, если завтра вы решите перейти на банку?Хотите изменить свои контроллеры?Я бы порекомендовал вам сделать так, чтобы различные слои вашего приложения были как можно слабее связаны, всегда работая с абстракциями (абстрактными классами / интерфейсами).

Answer 2

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

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

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

Answer 3

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

Answer 4

М в MVC относительно ASP.NET/MVC явно ссылается на модель просмотра

• В самом деле? Так что же означает V в ASP.NET/MVC?

Answer 5

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

Поэтому я пишу код своей модели в подпапках BOL и DAL.

DAL обрабатывают весь код базы данных - с BaseDAL, который имеет функции для получения наборов данных и функции для получения ВОЗВРАЩАЕМЫХ ЗНАЧЕНИЙ (с и без наборов данных) - я использую только хранимые процедуры.

И BOL, моделируют реальные объекты, и я вызываю соответствующий DAL всякий раз, когда мне нужны данные из базы данных. Таким образом, BOL - это фактический BOL, и я могу изменить DAL всякий раз, когда мне нужно.

Разделение является ключом к хорошему развитию, и разделение BOL от DAL, на мой взгляд, имеет смысл. Вы не должны делать вызовы БД из контроллера, это просто неправильно, ИМХО.

Answer 6

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

http://blogs.microsoft.co.il/blogs/gilf/archive/2010/06/21/revisiting-the-repository-and-unit-of-work-patterns-with-entity-framework.aspx

Answer 7

Когда у вас есть логика, которая не связана ни с потоком управления для определенной веб-транзакции, ни с доступом к данным для определенных объектов домена.См. Этот раздел официального документа MSDN о модульном тестировании ASP.NET MVC:

http://msdn.microsoft.com/en-us/magazine/dd942838.aspx#id0420058

Answer 8

Модели бизнес-уровня в MVC

РЕДАКТИРОВАТЬ (и немного напыщенно): Мой опыт работы с продуктами MS прекратился с MVC v1. Тогда ваша модель была сгенерирована L2S или EF или чем-то еще. Я знаю, что MVVM очень популярен для mvc, но этот шаблон говорит, что вещь, поддерживающая представление, - это модель представления, а вещь, связанная с бизнес-логикой, - это модель. Rails, merb, django, symphony, backbone.js и любой другой фреймворк mvc, о котором я знаю, называет то, что вы помещаете в модель бизнес-логики, и когда вы зайдете в википедию и посмотрите mvc, вы увидите, что это сказать о моделях

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

Не значит быть придурком, но если ASP.net MVC вызывает модели моделей представлений, они неправильно используют этот термин и полностью потеряли связь с шаблоном, названным в честь их структуры.