ASP.NET MVC, лучшие практики?

Question

[Larry Underwood]

День добрый. Изучаю ASP.NET MVC 5. В профессиональном окружении asp.net'чиков не имею, поэтому вынужден обратиться сюда. В ходе изучения матчасти сделал для себя некие выводы относительно правильного использования этой технологии. Мне необходимо удостовериться в правильности выводов. Ниже список утверждений, на каждый пункт которого просьба поставить в ответах +/- либо поправляющий комментарии. Разумеется все утверждения для какого-то среднестатистического случая, среднего проекта, средней сложности со "средними" требованиями.

1) Маршруты должны быть максимально короткими
2) Установка маршрутов с помощью RouteConfig предпочтительнее маршрутизации с помощью атрибутов (или в каких случаях следует все же использовать атрибуты)?
3) Формы и элементы HTML генерируем по возможности с помощью HtmlHelper
4) Методы действии должны быть максимально короткими. Логика валидации, аутентификации, обработка ошибок должна находиться в сторонних классах и подключаться с помощью атрибутов
5) Валидация данных должна происходить как на стороне клиента (JQuery), так и на стороне сервера
6) В представлении должен быть только вспомогательный c# код для построения разметки. И этот код должен быть минимален
7) Для CRUD с сущностями следует использовать кастомные биндеры, чтобы вместо сигнатуры метода действии вида:
void Action(int entityId);
иметь сигнатуру вида:
void Action(Entity currentEntity);
т.к. стандартный биндер для сигнатуры
void Action(Entity currentEntity);
будет каждый раз создавать новый инстанс Entity
8) ViewBag - костыль, который следует использовать только для простых случаев (прим.: передача тайтла в страницу)
9) Ajax-формы предпочтительнее, чем голый Ajax. Если в одной вьюшке напрашиваются оба подхода, то вьюшку следует отрефакторить
10) Все, что может быть сделано в разметке с помощью Razor, должно быть сделано с помощью Razor

Answer 1

[Дмитрий Ковальский]

Я конечно не гуру, но попробую озвучить свое мнение.
1)В общем и целом - да. Но что по вашему - короткий маршрут? короткие слова или малое число слешей? Тут все же качели читабельности неподалеку.
2)Я считаю да и причина довольно банальна - я не хочу лазить по всему проекту чтобы выяснить почему данный роут свалился в данный контроллер. Но есть исключение - регионы(Areas). У них свой RouteConfig и не исключено что он будет работать отлично от дефолтного.
3)Это вообще не проблема. Вам никто не запретит писать Javascript-логику, которая потом по ходу дела возьмет еще данных через API и сама нарисует view. Делайте как хотите, но это должно быть читабельно, поддерживаемо и хоть немного соответствовать поставленной задаче( не надо пользовать Angular только чтобы попользовать Angular)
4) Тут вы все в одну кучу смешали. Максимально короткими? В принципе да, но я хотел бы прочитав название точно угадать что он делает, а не узреть сюрприз в последствии. В остальном тоже соглашусь.
5) Предположим она нужна. Во первых уберите слово JQuery - сия библиотека к валидации имеет мало отношения. Во вторых на сервере как правило хватает проверок свойств ModelState.isValid и Model.isValid. Разумеется если ваша модель помечена всеми атрибутами, ограничивающими корректные значения. Тут правда есть одна заковыка - предположим у вас меняется логика валидации(поля обновились или еще какие-то телодвижения совершены). На практике вам нужно в двух местах обновлять одну и ту же логику, что не очень правильно(потенциальное дублирование кода, потенциальные ошибки забывчивости).
6)Может да, а может и нет. Повторюсь - клиентскую сторону можно лепить разными методами. Можно и Javascript-ом. В ASP.NET это не возбраняется. Это вообще нигде не возбраняется.
UPD:Программировать на C# внутри View не стоит. Тащить доп.данные тоже, хотя изредка такая необходимость возникает(словарь какой-нибудь подтащить). В основном код должен содержать вспомогательные функции- например сформировать какую-нибудь фразочку или проверить состояние объекта по нескольким полям вместо того чтобы писать кучу if в разметке.
END UPD.
7)Если честно не понял о чем вы.
8)Это не костыль, это транспортная система для коротких сообщений и простых типов. Использовать в качестве транспорта для модели тоже можно, но не безопасно с точки зрения приведения типов.
9) А что вы понимаете под "голый Ajax"? XmlHttpRequest? Да, на мой взгляд лучше его не использовать. Вторую часть вопроса не смогу комментировать без ответа на первую. Вьюшки бывают разные, некоторые подтягивают дополнительные данные по ходу дела. Тут нужно немного конкретики.
10) Не согласен и уже озвучивал ранее. Razor один из доступных инструментов. Можете использовать его - он хороший, а можете не использовать.

Comments

[Larry Underwood]

1 - Да, имел ввиду читабельность
4 - Под максимально короткими - имел ввиду, что в нем не должно быть try-catch с логгированием например или логики безопасности или какой-либо отладочной инфы (профиляция по памяти и времени например).
5 - Причина появления данного пункта - перфоманс - лишний запрос на сервер, если можно проверить какую-то часть данных на клиенте, почему бы не проверить. нет?
7 - имелось в виду про замену дефолтного биндера. стандартное решение - в метод контроллера приходит id сущности, ищем её в репозитории по id. Мне лень писать в каждом методе поиск по id, я хочу, чтобы за меня это делал биндер (та штука, которая подставляет значение в аргумент контроллера при запросе), короче говоря, для резолвинга сложных объектов проще написать свой биндер, нежели костылить дефолтный
8 - В контексте составных типов: можно, но не нужно для модели использовать ViewBag? На данный момент видится, что это только для всякой мелочи, а если найдется код, который использует его для передачи модели, то разработчику этого кода следует настучать линейкой по пальцам.
9 - Да, XmlHttpRequest. Когда для одного и того же элемента используется и Ajax.Forms и XmlHttpRequest.
Допустим таблица, допустим таблица с пагинацией. Допустим в каждой строке есть ячейка, в которой есть экспандер, по клике на экспандер должны подгружаться данные с сервера. Пагинацию делаем с помощью аякс формы, загрузку при клике на экспандер через голый аякс. Мне одному кажется, что одном файле, в одном элементе оба способа в раз сильно побъют читабельность?
10 - Ну, блин, должен же быть какой-то принятый стандарт разработки в ASP.NET. Неужели разрабатывают кто во что горазд? Т.е. пришел я в одну компанию, там делают все разметкой и стараются разбивать разметку на PartialView для переиспользования. Потом ушел я в другую компанию, а там через Js рисуют разметку и придется привыкать заново?

[Larry Underwood]

PS: спасибо за UPD внутри 6 пункта, это то, что я имел ввиду.

[Дмитрий Ковальский]

Максим Ванюшкин: 4) Логирование через IoC контейнеры можно и нужно делать там где возникает необходимость логирования. На уровне контроллера мы оперируем состоянием запроса - разумеется логировать ошибку уровня бизнес-логики на уровне контроллера не нужно. Логику безопасности можно делать через атрибуты метода контроллера.
5) Ну можно и съэкономить на этом. Но если серверная проверка должна быть обязательно, то клиентская уже опционально.
7)Для меня биндинг сущностей никогда не был особо проблемным. Для GET-запроса можно передавать идентификатор и тащить данные из репозитория. Для изменения и добавления мне больше нравится биндидить класс модели, а не набором входных параметров конструировать объект.
8)Есть базовая задача - дотащить объект модели во View для отрисовки. Если вам надо подтащить какие-то смежные данные, которые тоже нужны для отрисовки View(какие-то словари, доп. коллекции и прочее) - тогда создаете новый класс модели и в него пихаете все что вам нужно. Изначальная модель будет просто полем нового класса. ViewBag подойдет для пересылки сообщений вроде "Все хорошо" или "Все сломалось - вот причина".
9) Ну да, на мой взгляд подобный экспандер лучше вытащить в отдельный PartialView.
10) Я вас расстрою - да, это так. По хорошему вы должны уметь пользоваться разными инструментами или хотябы быть готовыми освоить новые. Представьте что я вам сделаю офер в компанию. Зарплата хорошая, проект интересный и сложный, все по белому, красиво, но вот беда - в проекте половина написана на Web Forms, вторая на всем зоопарке ASP.NET MVC, а на чем будут писаться новые проекты - неизвестно. Хороший, надежный проект как правило работает уже лет 8-10 и более. За это время много чего происходит и инструмент, использованный в 2007ом, как лучший в своем роде, может выглядеть ужасающе в 2016. Попробуйте подойти с этим к руководству и сказать что за полгода вы перепишите весь проект на шикарную технологию, а он услышит что вы собираетесь потратить 0,5-1,5млн рублей и на выходе получит то что и так имеет(сие вариация на недавний доклад Дино Эспозито, а не мой жизненный опыт).

[Larry Underwood]

Дмитрий Ковальский: Спасибо.

Answer 2

[AxisPod]

1. В настоящем проекте о маршрутах будет думать SEO.
2. Да. Атрибуты мусорят код, сложнее искать, лучше держать в одном месте. Да и вообще в плане атрибутов, лучше поменьше их использовать, сначала подумать над всеми вариантами без атрибутов и только в конце сравнить и оценить целесообразность их использования.
3. Ну здесь лучше так, чем писать голый хтмл, хотя в итоге и будет тяжелее.
4. Считайте, что атрибуты зло. В том что максимально простыми должны быть, это да, стараться использовать стандартные механизмы, если надо вернуть Json, используйте JsonResult (хотя в конкретном случае его возможностей может не хватить, но только в этом случае стоит использовать что-то другое). А сама логика естественно должна быть отделена и быть независима от веб, ничего не знать о веб и т.д.
5. На стороне клиента по желанию, на стороне сервера обязательна и маниакальна. Придти может всё.
6. Верно, только код который отвечает за отображение и никакой логики.
7. Ну свой биндер делать стоит, если не хватает стандартного механизма, но как не сделайте, всё равно придется создавать новый объект.
8. Лучше вообще никогда не использовать, усложняет понимание кода, усложняет поиск ошибок и т.д. Тут от ситуации конечно многое зависит. Но я бы сделал либо через агрегацию или наследование. Возможно сервис или еще как-нить.
9. Не совсем понял вообще о чём вы.
10. Ну тут всё зависит от шаблонизатора, можно и не Razor использовать. никто не запрещает.

Comments

[Larry Underwood]

Спасибо.

Answer 3

[Андрей Шедько]

1 и 2 уже ответили.
3. Лучше все на стороне фронта SPA. Razor мощный шаблонизатор, но....
4. Да, это нормальная практика.
5. Да.
6. Ногами пинать никто не будет, наверное, но блин, принцип разделения ответственности никто не отменял.
7. Используйте ViewModel.
8. Нет.
9.