Можно ли ударить по базе данных из пользовательского связующего?

Question

Скажем, у меня есть объект, который получает некоторые данные из HttpPost и некоторые из базы данных. Я думаю, что я хочу позволить ModelBinder перейти в базу данных/репозиторий для тех данных, которые отсутствуют в сообщении. На практике это хорошая или плохая идея?

Answer 1

Я решил изменить мой оригинальный ответ дал свое мышление на этих типах вещей развивалась с начала 2010 года

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

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

Answer 2

Я бы сказал, нет.

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

Answer 3

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

Answer 4

Я думаю, что это прекрасно, и использовать эту технику все время.

Единственные аргументы против очень педантичны и представляют собой аргументы в пользу философии. IMHO вы можете поместить код «заполнить недостающие опубликованные данные» в ваше приложение MVC как метод в вашем базовом контроллере против метода в вашем ActionFilter против метода в вашем ModelBinder. Все зависит от того, кто получит какую-то ответственность. Для меня модельное связующее может сделать намного больше, чем просто подключить некоторые свойства из опубликованных значений.

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

//logic not in modelbinder 
    public ActionResult Edit(KittyCat cat) 
    { 
     DoSomeOrthagonalDatabaseCall(cat); 

     return View(new MODEL()); 
    } 

против

//logic in model binder 
    public ActionResult Add(KittyCat cat) 
    { 
     return View(new MODEL()); 
    } 

Answer 5

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

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

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

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

Answer 6

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

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

2- Модульные связки и контроллеры являются частью уровня представления, реализованного с использованием ASP.NET MVC Framework. Если контроллерам разрешен доступ к базе данных с использованием интерфейсов репозитория, как не допускаются модели Binders?

Кроме того, есть ситуации, в которых вы бы «лучше» заполнили недостающие данные в вашей модели из Model Binders. Рассмотрим сценарий, в котором у вас есть раскрывающийся список на вашем представлении. При первом загрузке представления выпадающий список заполняется. Пользователь отправляет форму, но проверка не выполняется. Поэтому вам нужно снова вернуть форму. На этом этапе вам нужно будет повторно заполнить список в раскрывающемся списке «Модель». Делать это в контроллер выглядит некрасиво:

public ActionResult Save(DocumentViewModel viewModel) 
{ 
    if (!ModelState.IsValid) 
    { 
     viewModel.Categories = _repository.GetAll(); 
     return View(viewModel); 
    } 
} 

Я считаю, что инициализация Категории здесь некрасиво и как код запах. Что делать, если у вас было несколько свойств, которые необходимо было заполнить из базы данных? Что делать, если у вас было более одного действия с DocumentViewModel в качестве аргумента? Вам придется повторять этот уродливый шаг снова и снова. Лучший подход - заполнить все свойства модели с помощью модуля Binder и передать его контроллеру. Таким образом, объект, который передается контроллеру, находится в «согласованном» состоянии.