ASP.NET Core 2.0 Razor против Angular / React / и т. Д.

101

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

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

Я хотел узнать мнение экспертов о «новой» Razor против Angular / React и тому подобном. Меня особенно больше беспокоит производительность. Насколько Core 2.0 Razor соответствует фреймворкам рендеринга на стороне клиента? Различия незначительны? Наше приложение нацелено на 1 000 000 потенциальных пользователей (примерно 100 000 одновременно).

Заранее спасибо!

asp.net  angular  reactjs  razor 
— TchPowDog
источник
4
Под « новой бритвой » вы имеете в виду страницы Razor?
— Вернер
36
Итак, какой из них вы выбрали в итоге и как оно продвигается?
— stt106
5
Как вы справились (или продолжаете) с этим проектом? Я сейчас в почти идентичной вам ситуации и хотел бы получить обновления!
— JLo
10
Привет, JLo и stt106. Извините, что так долго не отвечал. В итоге мы выбрали интерфейс Angular и серверную часть API ASP.NET Core с использованием Azure SQL. До сих пор у нас все получалось отлично! Я бы предположил, что React будет похожей заменой Angular, если вам это удобнее. Мне пришлось изучить Angular, это был очень простой переход, и теперь мне он нравится!
— TchPowDog
Сравнение скорости ASP.Net Core и Angular / React не по теме? На него могут быть канонические ответы. На сегодняшний день у нас Core 2.2 и скоро 3.0.
— MikroDel

Ответы:

75

В итоге мы выбрали интерфейс Angular и серверную часть API ASP.NET Core с использованием Azure SQL. Мы протестировали Core Razor, и, хотя и лучше, чем предыдущая версия Razor, Angular в итоге оказался для нас намного быстрее. Что касается взаимодействия с пользователем, Angular (или React) намного превосходит по производительности. Аспекты привязки к модели Angular, которые мы обнаружили, являются огромным преимуществом серверного рендеринга. Однако использование Razor (или рендеринга на стороне сервера в целом), тем не менее, обеспечивает лучшую общую целостность данных и способствует лучшему переходу данных от внешнего интерфейса к внутреннему. Между интерфейсной структурой и API существует настоящая пропасть. Все данные, которые передаются на сервер, должны быть преобразованы в типизированные объекты - это означает, что вам нужно управлять двумя отдельными наборами моделей POCO. Это может вызвать проблемы, если объекты сервера и объекты интерфейса не совпадают. На данный момент Entity Framework Core не очень развит, поэтому у нас есть проблемы с обновлением объектов, запросами объектов, включая дочерние объекты и т. Д.

В целом, эта установка пока работает для нас отлично! Я бы предположил, что React будет похожей заменой Angular, если вам это удобнее. Мне пришлось изучить Angular, это был очень простой переход, и теперь мне он нравится!

— TchPowDog
источник
6
Что касается синхронизации двух наборов моделей POCO, существует действительно полезное расширение для VS, которое создает угловые интерфейсы из моделей MVC, проверьте пишущую машинку
— Энди Брэхэм
ну, лично, если бы мне пришлось использовать Angular, я бы использовал NoSql для части БД.
— Venzentx 05
2
Я не могу себе представить, чтобы выбрать бритву ASP.NET выше Angular. В прошлом ASP.NET давал разработчикам .NET знакомый код, но с RAZOR кривая обучения выше, чем с использованием Angular. MVC отделяет логику от HTML.
— Марк
1
@Mark Я не верю в это. Razor Pages идеальны, особенно в том, как они обрабатывают привязку данных. Они слишком ГОТОВЫ. Но, конечно, для его сценария angular как нельзя лучше подходит.
— Mosia Thabo
2
@MosiaThabo, Марк говорит не о Razor Pages, он говорит о Razor. Это то, что упоминал мой ОП. В моем первоначальном сообщении я не имел в виду Razor Pages (или, как мне кажется, теперь называется Blazor). Я специально говорил о рендеринге на стороне клиента и рендеринге на стороне сервера. Razor Pages - это разновидность Angular / React от Microsoft, которую, я думаю, они считают необходимой из-за преимуществ, которые у вас есть с Angular и React.
— TchPowDog
49

Используя Angular / React с API на стороне сервера:

  • вы устраняете процесс генерации HTML на стороне сервера и сохраняете процессор
  • api создает небольшую полезную нагрузку (json), а Razor (html) курса будет намного больше по размеру, постоянная полная перезагрузка страницы и обратная передача в оба конца. так что api и spa экономят пропускную способность
  • api и spa могут иметь разные сценарии управления версиями, масштабирования и развертывания.
  • Используя api, вы также можете поддерживать мобильное приложение, и если вы начнете с Razor, вам может понадобиться api в будущем

Но используя Angular / React, вы должны беспокоиться о клиентах:

  • клиент должен включить javascript
  • клиент должен иметь современные браузеры
  • у клиента должно быть достаточно мощное оборудование
  • SEO
— Мохсен Эсмаилпур
источник
1
Я понимаю разницу в двух фреймворках, меня больше интересовала производительность.
— TchPowDog
Для обоих существует один и тот же конвейер, но я не знаю, существует ли какой-либо тест для бритвенных страниц. эта ссылка может помочь - ASP.NET Razor Pages против MVC: как страницы Razor подходят для вашей панели инструментов?
— Мохсен Эсмаилпур,
1
Razor поддерживает мобильные устройства, перечисленные недостатки не имеют особого значения. Оба по-своему быстры. Я предпочитаю Angular, но оба они оптимизированы. Razor оптимизирует код, не используя дерево, как это делает MVC. Angular - это клиентская сторона, поэтому на самом деле он не использует дерево, но также в определенной степени оптимизирует данные в HTML.
— Ник Тернер
@NickTurner Я понял это не просто как просмотр веб-страницы на вашем смартфоне, а как полноценное собственное приложение. Например, приложение для Android, которое может получать данные из неизмененного серверного API как есть, с другой стороны, используя функции, предоставляемые Android - лучшую поддержку анимации, уведомления, всплывающие сообщения и т. Д.
— Рафаэль Шмитц
23

У меня нет тестов. Но у меня есть несколько проектов под управлением JQuery, Razor, .NET MVC (C #), AJAX. Не в том масштабе, за который вы беретесь.

Совет .. Обязательно все продумайте и следуйте лучшим практикам. Чтобы поддерживать удобство обслуживания, не забудьте разбить контроллеры, представления, модели на более мелкие и значимые группы. Когда я начал, я совершил ошибку, поместив все в один домашний контроллер и множество представлений в общей папке. Сначала все было хорошо, но когда началось расползание функций, это превратилось в беспорядок, и было трудно вернуться и изменить дизайн.

Я также использую Linq2SQL. Я совершил ошибку, создав модели для всего, а затем понял, что могу просто вернуть набор результатов из моих запросов в качестве модели. ага.

Если вы используете .NET MVC и беспокоитесь о производительности, вот с чем я столкнулся:

НЕ возвращайте частичные представления, которые создают большие блоки HTML! Обязательно все свести к минимуму. Избавьтесь от всего белого пространства. Используйте меньшие имена ID. Найдите время, чтобы создать как можно более легкий HTML-код. Верните JSON и попросите клиента выполнить часть работы.

Будьте осторожны при разработке CSS. Не используйте кучу встроенных стилей, найдите время, чтобы включить их в файлы CSS, которые впоследствии можно будет минимизировать.

То же самое касается JS на стороне клиента. Заманчиво поместить JS в частичные представления. Держите вещи организованными.

Рендеринг в IE ужасен. Особенно, если изображений много. Обязательно сжимайте изображения как можно сильнее, конечно без потери качества.

— Кейт Аймар
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.