asp.net mvc помощники со строгим контролем типов - Ваш объект привязки рендеринга должен совпасть с Вашим объектом регистрации?
я вижу, что asp.net mvc 2 имеет со строгим контролем типов, помог и смотрящий первоначально на способ, которым он работает, я думаю, возможно, что я делаю что-то не так в asp.net mvc 1 с точки зрения привязки данных, чтобы представить представление и отправить назад на контроллер.
У меня часто есть различные объекты для рендеринга представления и регистрации назад на контроллер. эта несправедливость?? Это кажется естественным, представляя представление, у Вас часто есть viewmodel, который имеет списки для, выпадает, и т.д. но для Вашей регистрации Вас только хотят свойства, которые необходимы для регистрации назад.
например, на пути в для рендеринга, мой viewmodel мог бы быть похожим на это
public class PersonViewModel
{
public int Age;
public string FIrst;
public JobCategory[] JobCategories;
public Sport[] Sports;
public int NumberOfChildren;
}
в этом случае, jobCategories и Спорт будет используемым для заполнения выпадающего поля. NumberOfchildren собирается просто быть вставленным HTML, и я не хочу его доступный для редактирования. Когда я хочу отправить, я только хочу пасовать назад тонкий объект только с отправленными свойствами, таким образом, у меня есть другой объект
public class PersonUpdater
{
public int Age;
public string FIrst;
public int JobCategoryId;
}
это единственные свойства, что я должен пасовать назад так свой контроллер, будет похож на это:
public ActionResult Update(PersonUpdater personUpdater)
{
_repository.UpdateModel(personUpdater).
}
таким образом, учитывая вышеупомянутое, принимая вспомогательные методы со строгим контролем типов (ниже) кажутся полезными для пути в, но затем может вызвать проблемы о регистрации назад на сервер, если Вы обращаетесь к различным свойствам.
http://weblogs.asp.net/scottgu/archive/2010/01/10/asp-net-mvc-2-strongly-typed-html-helpers.aspx
какие-либо мысли?
7 ответов
Реальная проблема - текущий принятый подход игнорирует SRP для бита просмотра моделей - форма редактирования действует как входная, так и выходная одновременно.
Люди еще не приняли разбиение View model на, как я их называю, input view model и output view model (для многих - даже создание view model layer - это слишком много). Поэтому - Mvc2 в настоящее время не имеет поддержки для этого (не предполагается, что вы имеете сильно типизированное представление, которое не является одновременно входным и выходным), главным образом, из-за неопределенности и отсутствия общепринятых подходов.
Но я действительно думаю, что есть выигрыш (хорошо... на самом деле это компромисс) в том, чтобы углубиться и разделить модель взгляда на 2 из них. И я не удивлюсь, если эта идея будет развиваться и в конечном итоге получит широкое признание.
На самом деле - нынешний подход даже имеет название - Принцип громоподобия . И если парни вроде Джереми Д. Миллера скажут, что это правильно, сообщество не будет беспокоиться и не будет искать ничего другого.
С практической точки зрения - некоторые из проблем можно смягчить, предоставив правильные метаданные (возможно, вы захотите проверить провайдера метаданных беглой модели ).
Вы можете указать, какое свойство вы отправляете в сильно напечатанном помощнике, ищите перегрузку с 3 параметрами.
Всего ничего плохого в вашем методе. Сильно напечатанные взгляды, чтобы помочь вам улучшить, поэтому нет TypPo не может встать на свой путь.
Большую часть времени автоматически связывающееся вещество не подходит тому, что мне нужно, поэтому я просто прибегаю к публикации в форму PharmCollection PROFTCHETER и GO MANUAL. Если вы можете использовать любую часть модели привязки магии, то все лучше для вас.
Связывание меньше не означает, что меньше данных размещены обратно на сервер. Все входные элементы в форме будут переданы, вы просто не увидите их как дискретные, сильно напечатанные, «автоматические» параметры. Если вы действительно хотите уменьшить данные по почте, вам нужно ограничить, какие входные элементы внутри конкретной формы вы публикуете. MVC все еще http в конце концов ...
Я бы посоветовал упростить это, используя только один объект для GET и POST. Поддержка кода здесь гораздо важнее/ценнее, чем сохранение нескольких байт для обновления.
Арнис приводит хорошие аргументы относительно SRP и других шаблонов дизайна, но предполагается, что петтеры должны быть адаптированы. На вашем месте я бы воспользовался справкой, которую для вас создал фреймворк mvc: используйте набранные помощники; используйте набранные объекты model/viewmodel для GET/POST и, если вам нужна более сложная привязка, создайте пользовательскую привязку.
Следите за своим кодом, и ur-приложение останется потрясающим.
Можно создать консольное приложение, а затем изменить его свойства в параметрах проекта на приложение Windows (а не консоль). Также можно создать приложение Windows Forms, которое не создает формы.
-121--4716432-Мне нравится ваше отношение DIY. Я также не смог найти никаких альтернатив Profiler, но вот статья , которая очень помогла мне одним из авторов книги Adobe Training from the Source . Я бы предложил провести точечные обзоры предложений по кодированию, изложенных здесь. HTH.
UPDATE: De MonsterDebugger также имеет функцию монитора памяти.
-121--3422740-Я также использую отдельные модели ракурсов для ввода [GET] и вывода [POST], если только две модели не идентичны. IMHO этот подход является более чистым, проще в обслуживании и более четко выражает, какие данные будут обновлены с помощью данного действия контроллера.
Существует стоимость в терминах LOC, но дополнительный код обычно не логика . В большинстве случаев я не чувствую, что дублирование некоторых автоматических свойств на двух объектах нарушает принцип DRY, и я думаю, что затраты оправданы, чтобы следовать SRP.
Другая стоимость, как вы отметили, заключается в том, что встроенные сильно типизированные помощники не работают так хорошо. Вы думали о том, чтобы писать своих помощников, которые поддерживают ваш шаблон? Например, можно перегрузить один из существующих помощников, чтобы можно было указать как источник (например, свойство входной модели), так и назначение (например, имя поля формы, которое разносится в выходную модель).
Я использую модель для ввода (отображается формой) и отдельную модель для вывода (отправляется формой). Проверка выполняется на выходной модели. Конкретная причина, по которой я это делаю, - раскрывающиеся списки. Вы хотите, чтобы список возможных значений был представлен пользователю, и они находятся во входной модели. В выводе или публикации из формы мне не нужен список возможных значений, я хочу знать, какие значения выбрал пользователь, если таковые имеются.
Просто глядя на вашу конкретную ситуацию, мне приходят в голову следующие моменты.
1) Эти две модели действительно очень похожи 2) Если вы добавляете "MiddleName", вам нужно добавить его в двух местах 3) Когда вы говорите "Я только хочу пройти назад тонкий объект "- фактический POST будет содержать тот же объем данных, независимо от того, привязаны ли вы к исходной модели или к новой (она будет содержать пару ключ-значение для каждого пользовательского ввода в форме) {{1} } 4) Вы исключаете возможность отображения данных на странице «Сохранено нормально» или «что-то недопустимое», поскольку они не являются частью модели
По этим причинам я бы рекомендовал использовать ту же модель для GET и POST действия.