Лучшие практики для ASP.NET MVC

В принципе, этот "вопрос" предназначен для объединения информации о лучших практиках в сообществе. Причины этого:

  • Явное отсутствие ресурса ASP.NET MVC на основе сообщества для лучших практик. Да, я знаю wiki.asp.net.
  • Мне досадно знать, что вики ASP.NET на ASP.NET MVC крайне невелики и ужасно устарели, и Microsoft больше нуждается в том, чтобы сообщать об этом еще до того, как сообщество сделает с ней что-нибудь.
  • Меня очень интересуют лучшие практики в целом, с большим опытом работы с ASP.NET MVC за последний год, но я также помню, что я не эксперт, и что я могу определенно улучшить. Этот пост, я считаю, может помочь этому и вам.

Я серьезно подумал о том, должен ли я задавать этот вопрос, даже если мы продолжим создание вопроса о мета о создании этого вопроса.:)

То, что я ищу, - это информация о лучших практиках по всем аспектам ASP.NET MVC. Контроллеры, модели, расширения, HTML-помощники, сборщики маршрутов, TDD.

В прошлом я нашел ресурсы, такие как Кази Манзур Рашид лучшие практики (часть 1 и 2) достаточно полезно, а также Maarten Balliauw взвешивание, но они немного иссякли, и я надеялся на более динамичное и растущее хранилище информации от разных людей, а не только на случайную запись в блоге у ученых. Информация, подобная этому, немногочисленна и далеко, а ресурсы сообщества ASP.NET MVC еще меньше.

MVC вообще

Model

Не стесняйтесь добавлять ссылки на модели

Просмотров

контроллер

Не стесняйтесь добавлять контрольные ссылки

Рекомендация:

  • Одна "лучшая практика" за каждый ответ
  • Потратьте время, чтобы объяснить, почему он должен быть предпочтительнее альтернатив.
  • Сначала прочтите существующие ответы - если вы видите тот, с которым согласны, вы можете его проголосовать; если вы не согласны, проголосовали и оставьте комментарий, объясняющий, почему.
  • Не стесняйтесь редактировать любой ответ, если вы можете расширить его, почему он "лучший"!

P.S. Пожалуйста, не просто ставьте "Anything" Phil Haack, Скотт Гатри, Rob Conery или Скотт Гензельман "!

Ответы

Ответ 1

Используйте T4MVC, чтобы устранить все магические строки и магические анонимные типы во всем проекте. Это поможет вам в рефакторинге позже в вашем проекте, и (кроме того, чтобы все еще обеспечить четкость ваших маршрутов), все вызовы Action получают соответствующие параметры. Он меняет такие вызовы:

<%= Html.ActionLink("Link text", "Products", "Details", new { id = Model.Id }) %>

В:

<%= Html.ActionLink("Link text", MVC.Products.Details(Model.Id)) %>

Ответ 2

  • IoC/DI для контроллера factory (поэтому я могу добавить IRepository, ISomeService в конструктор контроллеров)
  • никогда не обращаться к HttpContext напрямую, создавать обертку, чтобы ее можно было тестировать на уровне
  • Структура валидации для проверки привязки модели (xVal или FluentValidation). Встроенная проверка внутри MVC 1 является базовой
  • никогда не используйте "магические строки": для вызова контроллеров/действий из представления, для RouteLink, RenderPartial, RenderAction,...
  • никогда не используйте ViewData, создайте классы DTO ViewModel. Используйте AutoMapper для отображения данных из объектов домена в объекты ViewModel DTO для представления

Объекты ViewModel DTO:
Абстрактный класс BaseViewModel, свойства для отображения метаданных страницы, меню и все другие материалы, которые появляются на каждой странице. Все остальные классы ViewModel наследуются от BaseViewModel.

Ответ 3

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

Ответ 4

В то время как не сайт лучших практик, ниже сайт делает отличные вещи с asp.net MVC, который, вероятно, можно считать лучшей практикой.

http://www.codeplex.com/MVCContrib

Ответ 5

В книге "MVC in Action" есть 2 бесплатных главы.

http://www.manning.com/palermo/

Глава 12 - это лучшие практики.

Ответ 6

Держите контроллеры как можно более "тонкими". Просто им нужно проверить данные, поступающие из формы, а затем вызвать модель (которая выполняет всю реальную работу), чтобы получить данные, которые будут возвращены в следующем представлении.

Наличие сложных контроллеров типа разрывает концепцию MVC.