ASP.NET MVC - Как добиться многократного использования пользовательских элементов управления и поддержки СУХОЙ?

Первое сообщение, пожалуйста, будьте осторожны:)

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

Обратите внимание, что этот вопрос относится только к пользовательским элементам управления, которые требуют специальной обработки и логики при обратной передаче. У меня нет проблем с созданием красивого DRY-кода для пользовательских элементов управления, которые либо видны только (с использованием RenderPartial), либо требуют предварительной обработки для создания соответствующей ViewModel (с использованием RenderAction).

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

Чтобы дать конкретный пример, скажем, я хотел бы создать пользовательский элемент "Быстрое добавление", который содержит три поля ввода: имя, фамилию и название компании и кнопку отправки. Когда используется функция QuickAdd, следующие шаги должны выполняться независимо от того, на какой странице находится элемент управления:

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

Моя основная проблема с достижением DRY связана со всеми контроллерами, которые вызывают представления, которые содержат частичный вид, в конечном итоге должны иметь метод действия для обработки представления формы из Quick Add. Даже если я вырву логику для обработки информации в отдельный контроллер и вызову этот метод из каждого из других контроллеров, это кажется бременем, что каждый контроллер, который вызывает представления, которые имеют повторно используемые элементы управления, должен иметь эти знания.

Другой вариант, на который я смотрел, состоял в том, чтобы всегда использовать элемент многократного использования для конкретного метода/контроллера действия, но тогда нет возможности для этого контроллера знать, как правильно заново заполнить модель для конкретного контроллера, который вызывал который содержал средство многократного использования (на шаге 4).

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

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

Ответ 1

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

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

Я настоятельно рекомендую 6 советов для привязки модели ASP.NET MVC для более глубокого обсуждения темы наряду с некоторыми хорошими ссылками.

Ответ 2

Я не уверен, почему вы говорите, что форма быстрого добавления должна иметь метод действий в каждом контроллере, который его использует; если вы добавите функцию быстрого добавления в Html.BeginForm(); Html.EndForm(), вы можете иметь метод beginform указать имя действия и контроллера, поэтому вам нужен только один контроллер.

Я понимаю, откуда вы пришли; это то, о чем я думал. Хотя я не знаю всех ответов, у меня есть несколько идей для вас. Каждый метод действия контроллера вызывается через класс ControllerActionInvoker, который вы можете настроить. Этот класс обрабатывает все методы действий, поэтому здесь вы можете вставлять некоторые аспекты многоразового кода во все или некоторые методы действий.

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

Для проверки уже созданы компоненты проверки, которые предотвратят отправку страниц... вы также можете рассмотреть XVAL, который имеет некоторые другие приятные функции. Рамка Unity представляет собой контейнерную инфраструктуру IOC, динамическая инъекция которой поддерживает связь между собой и DRY, поскольку вы можете вводить все типы ссылок.

Кроме того, вы упомянули субконтроллеры; предварительный просмотр MVC имеет дополнительные функции, которые могут вас заинтересовать... например, у него есть метод RenderAction, который может отображать метод действия в другом представлении действий.

Надеюсь, это поможет... так что мне не хватает?

Ответ 3

Посмотрите на RenderAction и RenderPartial. Это канонические способы произвольного введения общего контроля в представление.

Используйте RenderPartial, если вы хотите включить данные как часть инфраструктуры ViewData.

Используйте RenderAction, когда вы хотите, чтобы данные были отделены от инфраструктуры ViewData. Данные будут получены из метода контроллера, указанного в RenderAction.

Ознакомьтесь с учебниками NerdDinner, если вы еще этого не сделали.