#model-view-controller #asp.net-mvc-3 #controller
#модель-представление-контроллер #asp.net-mvc-3 #контроллер
Вопрос:
Первоначально это должен был быть вопрос о том, как выполнить задачу, но теперь это превратилось в вопрос о наилучшей практике.
Я использую MVC (все еще новичок в нем), и я пытался создать метод, который может вызывать любой контроллер, который будет запускать общую функциональность. Внутри метода мне нужно было запустить метод TryUpdateModel контроллера. Вот где я столкнулся с препятствием — я не мог этого сделать, если метод не был В контроллере, потому что TryUpdateModel «недоступен из-за его уровня защиты» — он помечен как «защищенный». Если бы мне пришлось сделать этот метод закрытым для каждого контроллера, это разрушило бы всю цель использования метода в первую очередь, и мне пришлось бы копировать-вставлять много кода.
Итак, мне было интересно, почему этот метод защищен? Конечно, я, должно быть, упускаю что-то вопиюще очевидное. (И, пожалуйста, пролейте свет)
Что я в итоге сделал, создав свой собственный класс контроллера, который наследуется от базового класса контроллера. Этот новый класс содержит метод, который мне был нужен, чтобы быть общим для всех моих контроллеров. Теперь мои контроллеры наследуются от этого нового класса controller, который я создал, который, в свою очередь, наследуется от базового класса controller. Он хорошо работает и, похоже, отлично подходит для модели.
Мой вопрос — для тех, кто регулярно работает с MVC, эта модель плохая идея? Обычно это плохая идея — взять такой центральный класс, создать свой собственный и использовать его вместо этого?
Комментарии:
1. Некоторый базовый пример кода, описывающий то, что вы пытаетесь сделать, помог бы людям лучше понять вопрос
Ответ №1:
Это защищено, потому что эти методы принадлежат коду контроллера. Они являются расширениями контроллера, предназначенными для использования конкретно в контроллере. Тот факт, что они защищены, означает, что по замыслу это должно было произойти в контроллере. Возьмите asp.net веб-формы, например, Страница.IsPostBack предназначен для вызова изнутри самой страницы. Обычно магия привязки модели применяется к контроллеру, и, следовательно, TryUpdateModel также принадлежит туда. Возможно, вы пытаетесь слишком сильно упростить, но я понимаю, почему вы это сделали. Можете ли вы абстрагироваться на один уровень меньше? Используйте tryupdatemodel в вашем контроллере и любой дополнительный общий код в другом «общем» методе.
Обычно в mvc код в контроллере остается довольно простым, так что если !TryUpdateModel(модель), то вы просто возвращаетесь и позволяете modelstate / валидаторам творить свое волшебство. Это простой метод и, как правило, работает хорошо. Вы экономите 2/3 строки общего кода проверки, пытаясь реализовать этот другой метод?
Я не уверен, что (из-за ModelState и т.д.) Использование другого класса, который наследуется от контроллера, назначение которого на самом деле не является контроллером, Будет работать во всех случаях — так что будьте осторожны с этим. ModelState может передаваться неправильно и т.д.
Комментарии:
1. Адам, это в значительной степени то, что я искал. То, что вы говорите, имеет смысл. Метод — это не просто пара строк, и в зависимости от различных условий он вызывает TryUpdateModel с разными параметрами, так что вызов метода должен оставаться внутри функции. Тем не менее, ваше предложение было очень хорошим и подкрепило ваше объяснение. Я думаю, что маршрут, который я выбрал в конце, работает довольно хорошо и довольно близко соответствует задуманному шаблону. Спасибо за ответ.