ASP.NET MVC - Как достигнуть допускающих повторное использование пользовательских элементов управления и поддержать DRY?
Сначала отправьте поэтому быть нежными :)
При создании пользовательских элементов управления в ASP.NET MVC, что лучший способ состоит в том, чтобы структурировать код так, чтобы контроллеры, которые вызывают представления, которые используют пользовательские элементы управления разве, все не должны знать так много о средствах управления? Я хотел бы знать хороший способ поддержать DRY при использовании пользовательских элементов управления в ASP.NET MVC.
Отметьте, этот вопрос только принадлежат пользовательским элементам управления, которые требуют специальной обработки и логики на обратной передаче. У меня нет проблемы при создании хорошего кода DRY для пользовательских элементов управления, которые являются любой представлением только (использующий RenderPartial) или которые требуют, чтобы некоторая предварительная обработка создала соответствующий ViewModel (использующий RenderAction).
Кроме того, этот вопрос принадлежит только достижению допускающих повторное использование средств управления в рамках приложения. Я не волнуюсь по поводу возможности многократного использования между приложениями в этой точке.
Для предоставления определенного примера скажем, я хотел бы создать 'Быстрый, Добавляют' пользовательский элемент управления, который содержит три поля записи, Имя, Фамилию и Название компании и кнопку отправки. Когда функциональность QuickAdd используется, следующие шаги должны быть выполнены независимые от того, какая страница управление идет:
- Проверьте это, поля не были пусты, если они, покажите индикатор.
- Выполните поиск в репозиторий, чтобы видеть, существует ли Компания уже, если нет; создайте его.
- Создайте новый контакт, связанный или с существующей компанией или с недавно созданной компанией
- Повторно представьте существующую страницу. Если бы никакие ошибки проверки, пользователь видел бы ту же самую страницу снова, иначе ту же страницу с ошибками проверки.
Моя основная проблема с достижением DRY имеет отношение ко всем контроллерам, которые вызывают представления, которые содержат частичное представление, заканчивают тем, что имели необходимость иметь Метод действия обработать представление формы от Быстрого, Добавляют. Даже если я вспыхиваю логика для обработки информации в отдельный контроллер и вызываю тот метод от каждого из других контроллеров, на нагрузку кажется, что каждый контроллер, которые вызывают представления, которые имеют допускающие повторное использование средства управления, должен иметь то знание.
Другая опция, на которую я смотрел, состояла в том, чтобы иметь допускающий повторное использование контроль, всегда отправляют определенному методу действия / контроллер, но затем нет никакого пути к тому контроллеру, чтобы знать, как повторно заполнить модель соответственно для определенного контроллера, который вызвал представление, которое содержало допускающее повторное использование управление (на шаге 4).
Я знаю, что существует разговор о подконтроллерах в MVC 2 (от этого вопроса ASP.NET MVC - Содержавшие Пользовательские элементы управления), но так как это еще не там, что лучший способ состоит в том, чтобы структурировать код для достижения максимальной возможности многократного использования при поддержании DRY?
Существует ли альтернатива необходимости иметь все контроллеры, которые вызывают представления, которые используют допускающее повторное использование управление (с характеристиками той, описанной выше), имея необходимость иметь Метод действия обработать информацию от управления?
3 ответа
В конце сообщения вы спрашиваете "Есть ли альтернатива тому, чтобы иметь все контроллеры... должен быть Action Method для обработки информации от элемента управления"
Ответ на этот вопрос - написать пользовательскую связку модели . Ваша пользовательская связка модели может отвечать за заполнение значений из входящего элемента управления(ов) формой в модель или в свойства, используемые всеми контроллерами. Обычно, вы хотите отделить валидацию от привязки модели, но нет причин, чтобы вы не смогли их объединить.
Я настоятельно рекомендую 6 Советы для ASP.NET MVC Model Binding для более глубокого обсуждения темы вместе с некоторыми хорошими ссылками.
.Посмотрите на RenderAction и RenderPartial. Это канонические способы произвольного введения общего элемента управления в представление.
Use RenderPartial when you want to include the data as part of your ViewData infrastructure.
Use RenderAction when you want the data to be separated from the ViewData infrastructure.
Use RenderAction when you want the data to be separate from the ViewData infrastructure. Данные будут поступать из метода контроллера, который вы указали в RenderAction.
Посмотрите учебники NerdDinner, если вы еще этого не сделали.
.Я не уверен, почему вы говорите, что форма Quick Add должна иметь метод экшена в каждом контроллере, который его использует; если вы обернете функциональность Quick add в комбо Html.BeginForm(); Html.EndForm(), вы можете заставить метод beginform указать имя экшена и контроллера, так что вам нужен только один контроллер.
Я понимаю, откуда вы пришли; это то, о чём я думал. Хотя я не знаю всех ответов, у меня есть несколько идей для вас. Каждый метод экшена контроллера вызывается через класс ControllerActionInvoker, который можно настроить. Этот класс обрабатывает вызов всех методов экшена, так что здесь вы можете встроить некоторые аспекты кода многократного использования во все или некоторые методы экшена.
Посмотрите и на фильтры, так как существует множество фильтров, которые вы можете использовать или настроить этот огонь для методов экшена, которые его реализуют. Таким образом, код может выполняться до и после выполнения метода действия и результата.
Для проверки подлинности уже встроены компоненты проверки подлинности, которые будут препятствовать отправке страницы... вы также можете рассмотреть XVAL, который имеет некоторые другие приятные возможности. Фреймворк Unity - это контейнерный фреймворк IOC, динамический инжектор которого держит все в свободном доступе и DRY, так как вы можете инжектировать все виды ссылок.
Также вы упомянули субконтроллеры; предварительный просмотр MVC имеет дополнительные возможности, которые могут вас заинтересовать... например, в нем есть метод RenderAction, который может отрисовывать метод экшена в представлении другого экшена.
Надеюсь, это поможет... так что же я упускаю?