Какова единица возможности многократного использования в.NET приложения MVC?
Самыми расстраивающими для меня были ошибки компилятора, где код является правильным, но я поразил недокументированный угловой случай или что-то где несправедливость компилятора. Я запускаю учитывая, что я сделал ошибку и затем провожу дни, пытаясь найти его.
Редактирование: другим самым расстраивающим было время, я установил тестовый сценарий немного неправильно, таким образом, мой код был правильным, но тест не был. Это заняло дни для нахождения.
В целом, я предполагаю худшие ошибки, которые я имел, были те, которые не являются моим отказом.
6 ответов
В целом я бы согласился, что пользовательские элементы управления хороши с точки зрения инкапсуляции элементов пользовательского интерфейса, но я не думаю, что в MVC действительно многое изменилось. Если я помню, правильное повторное использование пользовательских элементов управления в классических проектах Asp.net было проблемой и никогда не было лучшим способом по-настоящему создавать повторно используемые компоненты. Большинство наборов инструментов пользовательского интерфейса, которые вы купили для классического ASP.net, не предоставляли вам пользовательских элементов управления, они предоставляли вам, по сути, серверные элементы управления и элементы управления javascript.
В вашем примере я бы, вероятно, создал или нашел плагин jquery (или фреймворка ur по выбору), который делал бы то, что вы хотели, на стороне клиента. Вы также можете создать вокруг него оболочку C #, аналогичную тому, что Telerik сделал с некоторыми элементами управления jquery UI. Я действительно думаю, что слово code-behind и даже viewstate исчезнут из вашего словаря, чем больше вы углубитесь в MVC.
Если вы посмотрите, какие проекты с открытым исходным кодом существуют для MVC, вы получите ответ относительно того, что вам следует делать.
Приложение MVC Contrib добавляет множество функций, создавая методы расширения и помощники. Их управление сеткой - это типичный способ создания повторно используемого компонента, который можно использовать в проектах
Telerik , создал некоторые расширения, которые обертывают элементы управления jquery и выполняют управление активами.
- Наконец, я думаю, если вы посмотрите в будущее , MVC имеет областей , которые, если я правильно интерпретирую, дадут вам возможность разбить ваш проект на несколько более мелких проектов.
Кроме того, что уже есть Предполагается, что ASP.NET MVC v2 будет иметь общие шаблонные элементы управления вводом, см. здесь . Вы можете прочитать, как другие люди применяют подобные техники, например, здесь :
У нас есть ровно 1 вызов метода для создания элемент формы «Html.InputFor». Как часть этого «InputFor», он исследует входная спецификация, которая собирает PropertyInfo, любые атрибуты, type, любые вызываемые модификаторы и выбирает подходящий InputBuilder. Вызовите InputFor (p => p.Id) и Id будет GUID? Это создает скрытый ввод элемент. Вызов InputFor (p => p.Customer.Address), а Address - это сложный тип? Это ищет партиал с тем же именем типа
Два способа, которые я могу придумать. Частичное представление, хотя на самом деле это не очень хорошо переносится из приложения в приложение, потому что вы перемещаете файлы ascx. Не большая боль, но не мое.
Я предпочитаю использовать WebControls . Они очень просты в mvc, и все, что вам нужно сделать, это сослаться на библиотеку в проекте и, возможно, в вашем конфигурационном файле, и готово.
Я думаю, что в некоторых ответах упущена возможность обратной передачи элементов управления. Один из способов справиться с этим - передать любую общую информацию через ViewData при рендеринге частичного представления. Затем он может отправить обратно в свой собственный элемент управления, который, в свою очередь, может перенаправить на UrlReferrer.
Это немного беспорядочно, а использование UrlReferrer представляет собой угрозу безопасности. Но это один из способов решения проблемы
Рассмотрев полезные ответы других, я попытаюсь ответить на свой вопрос.
Мне кажется, что основная трудность с эмуляцией UserControls в MVC заключается в том, что они пересекают проблемы, которые MVC стремится разделить. Селектор от / до даты UserControl в моем примере включает элементы модели, представления, управления и взаимодействия. Способность UserControls связывать все это вместе является именно той причиной, по которой они плохо вписываются в MVC.
Это означает, что для создания psuedo-UserControl в MVC требуется четыре отдельных элемента:
- Класс модели - в этом case - класс Interval или аналогичный
- PartialView, который знает, как преобразовать модель в HTML
- JQuery-скрипт для создания интерактивных слоев поверх PartialView ' s HTML
- ModelBinder, который может десериализовать постданные в экземпляр класса Model.
ModelBinder важен, потому что он имеет дело с данными, возвращаемыми от пользователя. Без него каждый контроллер, который хотел бы отображать селектор даты «от / до» в любом из своих представлений, должен был бы знать, как собрать шесть полей постданных - и как справиться, если они недействительны или некоторые из них отсутствуют.