Использование кода позади с ASP.NET MVC Views

Question

Считается ли плохой практикой использование выделенного кода в ASP.NET MVC Views? Сегодня с моими коллегами завязалась небольшая дискуссия по этому поводу, и мне было интересно узнать мнение сообщества.

Очевидно, что это не вариант при использовании другого MVC, такого как Rails, что заставляет меня думать, что он больше полагается на опору для тех, кто привык работать с традиционными приложениями ASP.NET Web Forms.

Answer 1

Я бы сказал, что использование ASP-NET MVC в коде - это плохая практика. MVC позволяет разделить задачи, где логика представления (в представлениях) отделена от логики приложения (в контроллерах). Использование code-behind будет смешивать логику представления и логику приложения с внутренними кодами, что приведет к потере некоторых преимуществ MVC.

Answer 2

Конечно, авторы ASP.NET MVC в действии советуют против этого, и я согласен. Это не обязательно, так зачем это делать? В ранних бета-версиях был включен файл с выделенным кодом, но он был удален в RTM (или незадолго до этого).

Как правило, это просто побуждает вас выполнять больше работы, не связанной с просмотром, чем вы должны делать в представлении, так как это вне поля зрения / вне ума.

Answer 3

Я широко использовал code-behind в моем первом проекте ASP.NET MVC (Preview 3!) - главным образом для выполнения таких вещей, как приведение ViewData ["foo"] в строго типизированные объекты данных, сбор данных представления в IEnumerables, чтобы я мог Зацикливайтесь на этом, такие вещи.

С введением строго типизированных представлений и прагматичным использованием шаблона Model-View-ViewModel (с ужасающим именем) я не пропустил кодовый элемент вообще, так как он был удален из структуры проекта непосредственно перед окончательный выпуск.

Теперь я твердо убежден, что независимо от того, какую обработку вы выполняете в выделенном коде своего представления, вам гораздо лучше смоделировать результат этой обработки в вашей модели представления, что позволяет контроллеру выполнять фактическую обработку. и сделайте вид максимально простым и легким. Это позволит вам протестировать логику обработки, упростить изменение представлений и создать, я думаю, гораздо более элегантное разделение между преобразованием ваших данных для отображения и их фактическим отображением.

Answer 4

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

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

Answer 5

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

Если вы новичок в Asp.Net MVC, я действительно рекомендую потратить некоторое время на изучение примера обеда для ботаников. Здесь есть бесплатная электронная книга и источник http://nerddinner.codeplex.com/.

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

Примечание: Если вы следите за электронной книгой, возьмите последний файл site.css из codeplex, иначе виртуальные карты земли не будут правильно выровнены.

НТН
Ральф

Answer 6

Я бы порекомендовал избегать кода в приложении MVC любой ценой. Использование кода, лежащего в основе, сводит на нет некоторые значения, которые вы получаете при использовании MVC Framework, такие как разделение интересов и т. Д. Вы хотите, чтобы доступ к данным, бизнес-правила, преобразование типов и тому подобное применялись в модели. Если вы обнаружите, что вам нужно конвертировать ваши типы данных, как упомянул Дилан, вы можете создать ViewModels. ViewModel - это, в основном, данные из фактической модели, которую вы хотите отобразить, в формате, в котором вы хотите их отобразить.

Answer 7

Следует отметить, что «Код позади» является функцией механизма просмотра веб-форм. Это действительно не имеет ничего общего с ASP.NET MVC.

Например, механизм просмотра Razor в MVC3 даже не поддерживает его.

Я бы ответил на ваш вопрос следующим образом: если вы не можете переключать движки представлений без переписывания ваших контроллеров (или даже ваших моделей), значит, вы неправильно используете шаблон MVC.

Вероятно, большая часть того, что вы делаете в файле .aspx.cs, действительно должна быть выполнена до того, как модель (или модель представления) будет передана в представление. Тем не менее, в проектах, которые я перенес из ASP.NET Web Forms в ASP.NET MVC, я оставил много кода позади. Например, я считаю более понятным и приятным использование элемента управления Repeater, чем пытаться использовать цикл for в веб-формах. Я все еще просто перебираю данные модели представления. Так почему не? Разделение интересов сохраняется (возможно, в большей степени на самом деле).

Я имею в виду, почему «наилучшая практика» для веб-форм внезапно становится неправильным способом представления веб-форм? В качестве простого примера рассмотрим Repeater, который назначает разные классы CSS для каждой второй строки таблицы. Почему мой контроллер (или даже моя модель) должен заботиться? Попытка встроить такую ​​логику в веб-формы быстро превращается в суп-тег и завершает спагетти. А теперь представьте что-нибудь более сложное.

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

В любом случае я обычно отключал ViewState в веб-формах и связывал данные в «Init». Тем не менее, часто было небольшое ViewState, от которого я не мог избавиться. Я поместил некоторый код в «Render», который перемещает это после формы (по умолчанию до). При переходе на MVC я иногда оставлял этот код. Итак, у меня есть сайты ASP.MVC, которые действительно используют Code Behind. Я просто осторожен, что это код, который специфичен для представления.

В новых проектах я, как правило, обнаруживал меньшую потребность в Code Behind на большинстве страниц. К счастью, механизмы просмотра, такие как Razor, сделали смешивание кода и разметки в строке намного менее болезненным для написания, чтения и обслуживания.