Что такое единица повторного использования в приложениях .NET MVC?

В традиционных приложениях ASP.NET Web Form, UserControls - отличный способ инкапсулировать функциональность, чтобы ее можно было повторно использовать. Однако UserControls не очень хорошо вписывается в модель MVC. Они часто сильно используют ViewState, и они размывают разделение опасений, которые поддерживает MVC.

Мой вопрос в том, как вам лучше всего расслоить функциональность, чтобы он мог использоваться совместно с приложениями MVC?

В качестве примера рассмотрим от/до даты-селектор UserControl, что:

  • позволяет пользователю выбирать две даты либо с использованием наложения JavaScript, либо путем ввода в день, месяц и год в отдельные поля.
  • может быть настроен по умолчанию на дату сегодняшнего дня и завтрашнего дня или на даты выбора разработчика
  • проверяет даты, которые возвращаются от пользователя, чтобы гарантировать, что дата до даты
  • предоставляет свойства From и To, к которым можно получить доступ с помощью кода

Как мне лучше построить что-то подобное в .NET MVC, чтобы я мог легко его повторно использовать?

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

Ответы

Ответ 1

В целом я бы согласился с тем, что пользовательские элементы управления хороши с точки зрения инкапсуляции содержимого пользовательского интерфейса, но я не думаю, что в MVC слишком сильно изменилось. Если я помню, что правильное повторное использование пользовательских элементов управления в классических проектах Asp.net было больно и никогда не было действительно лучшим способом по-настоящему создавать повторно используемые компоненты. Большинство наборов инструментов пользовательского интерфейса, которые вы приобрели для классического ASP.net, не предоставили вам пользовательские элементы управления, они предоставили вам по существу серверные элементы управления и элементы управления javascript.

В вашем примере я бы, вероятно, создал или нашел плагин jquery (или ur framework of choice), который сделал то, что вы хотели на стороне клиента. Вы также можете создать обертку С# вокруг нее, аналогичную тому, что Telerik сделал с некоторыми элементами управления jQuery UI. Я думаю, что слово code-behind и даже viewstate исчезнет из вашего словаря, чем больше вы попадете в MVC.

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

  • Приложение MVC Contrib добавляет множество функций, создавая методы расширения и помощники. Их управление сеткой является типичным способом создания повторно используемого компонента, который можно использовать в проектах

  • Telerik, создал некоторые расширения, которые переносят элементы jquery и управляют активами.

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

Ответ 2

Кроме того, что уже было предложено, ASP.NET MVC v2 будет иметь общие шаблонные элементы управления вводами, см. здесь. Вы можете прочитать, как другие люди делают подобные методы, например здесь:

У нас есть ровно 1 вызов метода для генерации элемент формы, "Html.InputFor". В виде часть этого "InputFor", он исследует входная спецификация, которая собирает PropertyInfo, любые атрибуты, тип, любые модификаторы, называемые, и выбирает соответствующий InputBuilder. Вызовите InputFor (p = > p.Id), а Id - GUID? Это создает скрытый ввод элемент. Вызовите InputFor (p = > p.Customer.Address), а адрес - сложный тип? Это ищет частично с тем же именем типа

Ответ 3

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

Мне кажется, что ключевая проблема с эмуляцией UserControls в MVC заключается в том, что они пересекают проблемы, которые MVC ставит перед собой. Селектор from/to date UserControl в моем примере включает элементы Model, View, Control и interation. Возможность UserControls связать все это вместе - это именно то, что они не подходят в MVC.

Это означает, что для создания psuedo-UserControl в MVC требуется четыре отдельных фрагмента:

  • Класс модели - в этом случае класс Interval или аналогичный
  • PartialView, который знает, как отображать модель в HTML
  • jQuery script для интерактивности слоя поверх PartialView HTML
  • ModelBinder, который может десериализовать postdata в экземпляр класса Model.

ModelBinder важен, поскольку он касается данных, возвращаемых от пользователя. Без этого каждый контроллер, который хотел бы отобразить селектор даты/даты в любом из его представлений, должен был бы знать, как собрать шесть полей postdata - и как справиться, если они были недопустимыми или некоторые из них отсутствовали.

Ответ 4

Два способа, о которых я могу думать. Частичный вид, хотя это не очень хорошо переносится из приложения в приложение, потому что вы перемещаете файлы ascx. Не большая боль, но не мой аромат.

Я предпочитаю использовать WebControls. Они очень легкие в mvc, и все, что вам нужно сделать, это ссылаться на библиотеку в проекте и, возможно, в ваш файл конфигурации и там вы идете.

Ответ 5

Я думаю, что некоторые из ответов упустили функциональность управления обратной связью. Один из способов справиться с этим - передать любую общую информацию через ViewData при рендеринге частичного представления. Тогда он мог бы вернуться к собственному контролю, который, в свою очередь, мог бы перенаправляться на UrlReferrer.

Его немного беспорядочно, и использование UrlReferrer создает угрозу безопасности. Но это один из способов решения проблемы.

Ответ 7

В качестве пользовательских элементов управления, предоставляемых в Web-форматах ASP.NET, MVC предоставляет множество способов сделать элементы управления и код, которые можно использовать повторно в другом приложении.

Использование Partials Если ваш частичный код имеет некоторую логику С# и отображает html с использованием кода Razor/aspx, то он должен поддерживать их в файле бритвы.

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

Запись кода в виде отдельной библиотеки С# Если какой-либо код слишком распространен для каждого приложения, которое вы делаете. Например, вы пишете систему аутентификации участника или какую-то глобальную функцию (С#), которая используется в каждом приложении вы создали их в отдельном решении, чтобы его можно было использовать в другом приложении, которое вы делали каждый раз, когда пытаетесь создать новое приложение в будущем.