Почему Razor Pages рекомендуемый подход для создания веб-интерфейса в Asp.net Core 2.0?

Ответ 1

Razor Pages оптимизированы для рабочих процессов на основе страниц и могут использоваться в этих сценариях с меньшим количеством движущихся частей, чем в традиционных моделях MVC. Это связано с тем, что вам не нужно иметь дело с контроллерами, действиями, маршрутами, моделями представления и представлениями (как обычно). Вместо этого ваш маршрут основан на соглашении, а ваша PageModel служит вашим контроллером, действиями и ViewModel в одном. Страница, конечно, заменяет вид. Вам также не нужно иметь столько папок, сколько в MVC, что еще больше упрощает ваш проект.

Ядро ASP.NET - более простые приложения ASP.NET MVC со страницами Razor, статья MSDN за сентябрь 2017 года, написанная Стивом Смитом:

[Razor Pages] provide

• более простой способ организации кода в приложениях ASP.NET Core, поддерживая логику реализации и модели представления ближе к коду реализации представления.
• Они также предлагают более простой способ начать разработку приложений ASP.NET Core,

В этой статье содержится дополнительная информация о том, почему использовать Razor Pages поверх MVC для рабочих процессов на основе страниц. Очевидно, что для API вы все равно захотите использовать контроллеры.

Стороннее редактирование - недостатки классической организации папок MVC

ASP.NET Core - функциональные фрагменты для ASP.NET Core MVC, более старая статья MSDN от сентября 2016 г., описывает, почему классическая конвенция MVC по организации представлений и контроллеров может иметь недостатки для более крупных проектов. В статье приведен пример четырех слабо связанных концепций приложений: ниндзя, растения, пираты и зомби. В статье описан способ структурирования их вне соглашения о папках по умолчанию путем организации файлов в папки по функциям или областям ответственности.

Ответ 2

Из статьи "Разработка современных веб-приложений с помощью ядра asp.net" (здесь pdf):

MVC: при использовании контроллеров и представлений приложения часто имели большие контроллеры, которые работали со многими различными зависимостями и моделями представления и возвращали много разные взгляды. Это приводило к большой сложности и часто приводило к тому, что контроллеры не следовали Single Responsibility Principle или Open/Closed Principles эффективно.

Razor Pages решает эту проблему проблема путем инкапсуляции серверной логики для данной логической "страницы" в веб-приложении. Страница Razor, которая не имеет серверной логики, может просто состоять из файла Razor (например, "Index.cshtml"). Однако, большинство нетривиальных Razor Pages будет иметь связанную модель страницы класс, который по соглашению называется тем же, что и файл Razor с расширением .cs (например, Index.cshtml.cs). Этот класс модели страницы сочетает в себе обязанности контроллера и модели представления. Вместо того, чтобы обрабатывать запросы с помощью методов действия контроллера, обработчики модели страницы, такие как 'OnGet()' выполняется, отображая связанную с ними страницу по умолчанию.

Бритвенные страницы упрощают процесс построения отдельные страницы в приложении ASP.NET Core, в то же время предоставляя все архитектурные функции ASP.NET Core MVC. Они являются хорошим выбором по умолчанию для новой функциональности на основе страниц.

Когда использовать MVC:

Если вы создаете веб-API, шаблон MVC имеет больше смысла, чем пытаться использовать Razor Pages. Если ваш проект будет предоставлять только конечные точки веб-API, в идеале вам следует начать с проекта веб-API шаблон, но в противном случае его легко добавить контроллеры и связанные конечные точки API в любое ядро ASP.NET приложение. Вам также следует использовать подход MVC на основе представлений, если вы переносите существующее приложение из ASP.NET MVC 5 или более ранней версии в ASP.NET Core MVC, и вы хотите сделать это с наименьшим количеством усилия. После того, как вы сделали первоначальную миграцию, вы можете оценить, имеет ли смысл принять Razor Pages для новых функций или даже в качестве оптовой миграции.

Примечание: Независимо от того, решите ли вы создать свое веб-приложение, используя Razor Pages или MVC, ваше приложение будет иметь аналогичная производительность и будет включать поддержку внедрения зависимостей, фильтров, привязки модели, проверки и т.д.

Обновление: Еще несколько причин, по которым я читал эту проблему github, прокомментированную Скоттом Саубером:

Мы используем Razor Pages для [сложного] портала медицинского страхования... У нас есть 60+ страницы, и я могу сказать, что для рендеринга на сервере HTML я никогда не вернусь к MVC. Это также не только для простых вещей. Домен медицинского страхования по своей сути является сложным и сочетает это с тем фактом, что это мультитенантное приложение (мы продаем продукт другим страховым компаниям), что добавляет сложности, поскольку приложение легко настраивается, поскольку разные страховые компании делают вещи немного по-разному..

Зачем его использовать?

• Razor Pages по умолчанию более безопасны. Razor Pages предоставляет проверку AntiForgeryToken по умолчанию. Кроме того, вы соглашаетесь с тем, какие свойства вы хотите привязать к модели через [BindProperty], что ограничивает вашу подверженность чрезмерным публикациям атак.

• Razor Pages имеет лучшую структуру папок по умолчанию, которая лучше масштабируется. В MVC структура папок по умолчанию просто не масштабируется. Наличие отдельных папок для представлений, контроллеров и часто моделей представления, когда все три в конечном итоге тесно связаны друг с другом, - это огромная PITA для работы. В конечном итоге вы переходите на все 3 папки и перемещаетесь по куче в любое время, когда вам нужно добавить или изменить функцию. Это ужасно Вот почему я выступал за Feature Folders. С помощью Razor Pages ваша PageModel (Controller + ViewModel) находится в той же папке, что и View. Вы можете просто нажать F7, чтобы переключаться между ними, что также очень удобно.

• Приводит к более удобному для сопровождения коду, который лучше масштабируется. С MVC было очень легко раздуть Контроллер с помощью действий 10+. Часто эти Действия никоим образом не были связаны друг с другом (за исключением, возможно, перенаправления между ними). Это усложнило навигацию по Контроллеру для поиска кода. Хуже того, если бы в контроллере тоже были приватные методы, это добавило бы метод к разложению. С помощью Razor Pages практически невозможно раздуть вашу модель страницы с помощью несвязанных методов с вашей страницей. Все, что вы помещаете в свою PageModel, относится к вашей странице.

• Модульное тестирование проще. С контроллером у вас может быть 8 действий, и некоторые из ваших зависимостей, в которые вы вводите, были связаны только с одним или двумя действиями. Таким образом, при модульном тестировании одного Действие вам либо нужно максимизировать их, либо пропустить ноль, оба из которых кажутся грубыми (это можно решить немного с помощью шаблона Builder). С Razor Pages ваши зависимости на 100% связаны с действиями GET и POST, с которыми вы работаете. Это просто естественно.

• Маршрутизация проще. По умолчанию в Razor Pages маршрутизация соответствует структуре вашей папки. Это облегчает выполнение вложенных папок. Например, все наши страницы администрирования персонала находятся в папке /Administrator, а все страницы сотрудника - в папке /Employee. Мы можем авторизовать всю папку и сказать, что человек должен быть администратором, чтобы получить доступ к любой подпапке в /Administrator, что было гораздо проще сделать, чем с несколькими контроллерами, составляющими функции администратора.

Я думаю, что большие вещи.

Обновление 2:

Речь идет о некоторой сложности шаблона MVC, который не дает прямого ответа на вопрос, но может быть полезен: инженер-менеджер в Facebook сказал (здесь) об их "достаточно" большой базе кода и большой организации, "MVC действительно очень быстро усложнился", заключив, что MVC не масштабируется. Сложность системы становилась экспоненциальной каждый раз, когда они пытались добавить новую функцию, делающую код "хрупким и непредсказуемым". Это становилось серьезной проблемой для разработчиков, плохо знакомых с определенной базой кода, потому что они боялись прикоснуться к коду, чтобы не сломать что-либо. В результате MVC развалился на Facebook.

Ответ 3

Microsoft возвращается к подходу WebForms, чтобы упростить структуру проекта, доверяя мантре "Конвенция по конфигурации", скрывая конфигурацию от разработчика, чтобы ускорить работу. Но у него есть дискомфорт, что все снова будет смешано. Я не похож на умный ход для организации. Но эй! Что-то новое должно привлечь внимание разработчика к Microsoft.

Если ваша страница использует веб-API MVC для REStful, гораздо проще использовать страницы Razor. Если нет, я бы рекомендовал вам использовать Core MVC.

В огромных проектах, где модель и контроллер находятся вместе в одном файле, обслуживание будет кошмаром. Он хорошо работает для кладов, которые имеют всего 2 свойства, но это нарушает принцип Open Close ООП. Вы должны проектировать и использовать архитектуру, которая может расти со временем (Extensible) и по-прежнему быть стабильной и логичной (без повторной настройки проекта), просто расширьте ее, используя тот же шаблон.

Ответ 4

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

Как насчет поддержки действий общего доступа и группировки на страницах Razor. Если вы посмотрите на контроллеры MVC, то увидите, что вы можете группировать действия контроллера на основе их функциональности. Вы могли бы сказать, что Домашняя страница - такая функциональность. Тогда у вас есть HomeController с About() и Contact() в нем, но с Razor Pages это будут разные страницы. Может быть, у вас есть большой HomeController с 5 другими видами в нем. Все они могут быть сгруппированы в одном контроллере HomeController.

Контроллер имеет две вещи, которых нет у Razor Pages:

1. Совместное использование: вы можете обмениваться действиями Контроллера между различными страницами, иногда действия контроллера не связаны только с одной страницей, но могут быть разделены между несколькими страницами. Помните, что действия контроллера также могут возвращать только данные (JSON/XML/и т.д.). Иногда то, что они возвращают, также может использоваться разными страницами.
2. Группировка. Вы можете группировать связанные действия контроллера в одном контроллере. Хорошо, если вы фанат маленьких файлов Controller, вы этого не сделаете. Я делаю. Я группирую свои контроллеры на основе функциональности. Это значительно упрощает навигацию.

Что такое способ обработки страниц Razor: использование каталогов, я думаю:

• Группировка: Если у нас есть HomeController, то мы можем создать подкаталог Home со всеми домашними страницами в нем.

Вопрос: Для простого дома этого было бы достаточно. Но допустим, у нас есть XController, который использует для всех действий один и тот же репозиторий. Вы можете инициализировать этот репозиторий в функции Initializer XController. Но для страниц в подкаталоге X вам придется сделать это снова для всех действий X. Это сухой?

• Совместное использование: Вы можете создать подкаталог "Общий доступ" и, в этом разделе, каталоги с функциями, которые должны совместно использоваться страницами.

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

Как бы вы это сделали?

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

Ответ 5

В 2013 году разработчики были на форумах с вопросом: "Что означает Microsoft, Silverlight не рекомендуется...???" Только на этот раз MVC будет объявлен мертвым и да здравствует MVVM. И вы, вероятно, можете ожидать, что MVC будет выбрасываться в кучу металлолома медленно, но с ускорением примерно через 18 месяцев, и любое время, потраченное на изучение MVC, пойдет в ту же кучу металлолома. Кроме того, MVVM выглядит легко, но требуется год, чтобы освоить его и действительно сделать это правильно.