2009-07-14 12 views
4

Мы разрабатываем довольно большое приложение с использованием ASP.NET MVC, и в начале мы видели, что было бы полезно иметь абстрактный базовый контроллер с общими действиями CRUD (новый, сохранить, удалить ...) плюс действие по умолчанию для списка , В нашем случае у нас есть 20+ объектов, управляемых с помощью таких контроллеров.Является ли абстрактным контроллером CRUD хорошей идеей?

Это работает и позволяет избежать дублирования кода и делает приложение более однородным, но когда вы видите контроллер, трудно понять, какие действия он выполняет, и он может реализовать некоторые действия, которые не должны существовать. И, например, представьте, что вы хотите редактировать передачу имени, а не идентификатор, вам нужно создать новое имя EditByName (имя), и даже это сделать, вы все еще имеете действие Edit (id), потому что оно находится в базе.

Для меня все это немного пахнет, но я не нашел ни одного примера, показывающего альтернативу, потому что приложения MVC, которые я вижу, имеют довольно узкий домен. Есть рекомендации? Любой пример? (Я не обязательно должен быть в ASP.NET MVC, проблема, я думаю, является общей для любой среды MVC).

ответ

3

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

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

1

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

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

2

Я создал версию того, что вы предлагаете (хотя, по общему признанию, относительно не ООП), и она очень хорошо работает для меня.

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

protected ActionResult DisplayValidateAndEditModel<TModel>(TModel model, string modelPrefix, 
             string editViewName, string successActionName, object routeValues, string successMessage, 
             string[] includeProperties, bool acceptFiles 
           ) where TModel : class 

и

protected ActionResult DisplayValidateAndEditModel<TModel>(TModel model, string modelPrefix, 
             string editViewName, string successActionName, string successMessage, 
             string[] includeProperties 
           ) where TModel : class 

Правка охватывает создание/чтение/обновление и удаление будет удалить. Листинг - это одна строка в контроллере - я просто получаю группу моделей и добавляю к viewdata.

Оба метода проверяют, является ли это сообщение.Если нет, они возвращают представление. Если это так:

  • редактирует вызовы TryUpdateModel, а также выполняет некоторые проверки xVal. Если все в порядке, оно перенаправляет на successAction с любыми параметрами routeValues. Если нет, он снова отображает представление. includeProperties можно передать так, чтобы мой контроллер мог точно указать, что может получить обновления. И acceptFiles добавляет дополнительные функции, когда ищет проводку файлов и, если есть, помещает их в базу данных и создает связь между файловой записью и моделью.

  • Удалять обновляет свойства этой модели CANCEL_DATE и Cancel_User (у меня есть ICancelable интерфейс) и перенаправляет к действию успеха

0

Для меня все это попахивает ..

Этот же запах здесь :-)

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

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

Попробуйте переместить логик в Модель. Используйте фильтры и CustomModelBinder.

+0

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

0

Просто как будто: Как вы знаете, ASP.NET MVC поддерживает базовые строительные леса, такие как Ruby on Rails. Вы можете подумать о том, чтобы настроить файлы T4, используемые для создания представлений Create, Update, Details, чтобы удовлетворить ваши конкретные потребности.

http://blogs.msdn.com/webdevtools/archive/2009/01/29/t4-templates-a-quick-start-guide-for-asp-net-mvc-developers.aspx

+0

Леса могут быть полезны в некоторых случаях, но создает много дублированного кода. –

+0

Имеет ли значение, если дублированный код * сгенерирован * дублированный код? Если это нужно изменить, вы можете просто генерировать его по-другому ... – glenatron

+0

Неважно, когда сгенерированный код не следует вашей архитектуре. Если вы не использовали свой собственный механизм сборки для создания кода лесов; из коробки, строительные леса разрушат множество концепций современной архитектуры. правило DRY должно храниться в духе, а не только в коде, который вы вводите. На строительные леса не следует полагаться. – Apache

 Смежные вопросы

  • Нет связанных вопросов^_^