Код позади в ASP.NET MVC

Question

Какое назначение кода для файла представления в ASP.NET MVC помимо установки универсального параметра ViewPage?

Answer 1

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

• Унаследованные элементы управления устаревшими элементами управления ASP.NET - если альтернатива недоступна или требуется временное решение.
• Просмотр логики, требующей рекурсии, для создания некоего вложенного или иерархического HTML.
• Просмотр логики, которая использует временные переменные. Я отказываюсь определять локальные переменные в моем супе тега! Я хотел бы, чтобы они как свойства в классе представления по крайней мере.
• Логика, характерная только для одного вида или модели и не принадлежащая HtmlHelper. В качестве примечания, я не думаю, что HtmlHelper должен знать о каких-либо классах 'Model'. Хорошо, если он знает о классах, определенных внутри модели (например, IEnumerable, но я не думаю, например, что у вас когда-либо будет HtmlHelper, который принимает ProductModel. Методы HtmlHelper становятся видимыми из ВСЕХ ваших представлений, когда вы набираете Html + dot, и я действительно хочу максимально сократить этот список.
• Что, если я хочу написать код, который использует HtmlGenericControl и другие классы в этом пространстве имен для генерации моего HTML объектно-ориентированным способом (или у меня есть существующий код, который выполняет то, что я хочу портировать).
• Что, если я планирую использовать другой движок представления в будущем. Я мог бы хотеть оставить некоторую логику в стороне от супа тега, чтобы потом было легче использовать его снова.
• Что делать, если я хочу иметь возможность переименовывать свои классы Model и автоматически изменять рефакторинг моего представления без необходимости переходить к view.aspx и изменять имя класса.
• Что, если я координирую работу с HTML-дизайнером, которому я не доверяю, чтобы он не испортил «суп-тег» и захотел написать что-нибудь еще, кроме простого зацикливания в файле .aspx.cs.
• Если вы хотите отсортировать данные, основываясь на параметре сортировки представления по умолчанию. Я действительно не думаю, что контроллер должен сортировать данные для вас, если у вас есть несколько вариантов сортировки, доступных только из представления.
• Вы действительно хотите отладить логику представления в коде, который на самом деле выглядит как .cs, а не HTML.
• Вы хотите написать код, который может быть позже извлечен и повторно использован в другом месте - вы просто еще не уверены.
• Вы хотите создать прототип того, что может стать новым HtmlHelper, но вы еще не решили, достаточно ли он универсален или нет, чтобы оправдать создание HtmlHelper. (в основном то же, что и предыдущий пункт)
• Вы хотите создать вспомогательный метод для рендеринга частичного представления, но вам нужно создать для него модель, извлекая данные из представления главной страницы и создавая модель для частичного управления, основанную на текущей итерации цикла.
• Вы полагаете, что программирование сложной логики В ОДНОЙ ФУНКЦИИ является устаревшей и неосуществимой практикой.
• Вы сделали это до RC1 и не столкнулись с какими-либо проблемами !!

Да! Некоторые представления вообще не нуждаются в заднем коде.

Да! Это отстой, чтобы получить глупый файл .designer, созданный в дополнение к файлу .cs.

Да! Раздражает, когда рядом с каждым видом появляются эти маленькие + знаки.

НО - На самом деле не так уж и сложно НЕ помещать логику доступа к данным в код позади.

Они, безусловно, НЕ зло .

Answer 2

В конечном итоге, вопрос, который вы себе задаете, таков:

Этот код А) Обрабатывает, хранит, извлекает, выполняет операции с данными или анализирует их, или Б) Помогает ли отображать данные?

Если ответ А, он принадлежит вашему контроллеру. Если ответ B, то он принадлежит в представлении.

Если B, это в конечном итоге становится вопросом стиля. Если у вас есть довольно длинные условные операции, чтобы попытаться выяснить, отображаете ли вы что-то для пользователя, вы можете скрыть эти условные операции в коде в свойстве Property. В противном случае кажется, что большинство людей вставляют код в строку интерфейса с помощью тегов <%%> и <% =%>.

Первоначально я поместил все свою логику отображения в теги <%%>. Но недавно я решил добавить что-нибудь грязное (например, длинное условное выражение) в мой код, чтобы сохранить мой XHML чистым. Хитрость в этом заключается в дисциплине - слишком заманчиво начинать писать бизнес-логику в коде, а это именно то, что вы должны не делать в MVC.

Если вы пытаетесь перейти от традиционного ASP.NET к ASP.NET MVC, вы можете избегать кода, пока не почувствуете практические действия (хотя это по-прежнему не мешает вам поместить бизнес-логику в <%%>.

Answer 3

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

Answer 4

Нет цели. Только не используйте его, кроме как для настройки модели

ViewPage<Model>

См. этот блог для получения дополнительной информации.

Answer 5

Codebehind обеспечивает некоторую строгую типизацию, а также поддержку intellisense, которую вы получаете в представлении. Если вас не волнует ни одна из этих двух функций, вы можете удалить ее.

Например, я обычно использую NVelocity ViewEngine, потому что он чистый и довольно простой.

Answer 6

Это отличный вопрос. Не существует MVC в среде ASP.NET без использования определенного шаблона MVC.

View = aspx

Контроллер = aspx.cs (код позади)

Модель = POCO (простые старые объекты C # / VB / .NET)

Мне интересно, почему полезна дополнительная функциональность MVC framework. Я много работал с Java nd MVC и Java Struts несколько лет назад (2001) и обнаружил, что концепции MVC являются решением проблем организации и разработки интернет-приложений в то время, но потом обнаружил, что codebehind упростил концепцию контроллера и быстрее развивался и общался с другими. Я уверен, что другие не согласны со мной, и я открыт для других идей. Самая большая ценность, которую я вижу для MVC, - это шаблон фронт-контроллера для разработки в Интернете, единый источник входа для Интернет-приложений. Но, с другой стороны, этот шаблон довольно просто реализовать с помощью современных технологий ASP.NET. Я слышал, как другие говорят, что модульное тестирование - это обоснование. Я могу понять, что мы также использовали JUnit с нашей средой MVC в 2001 году; но я не был убежден, что это упрощает тестирование для использования инфраструктуры MVC.

Спасибо за чтение!