ASP .Net Core с бритвенными страницами и угловыми для пользовательского интерфейса

Question

Наше корпоративное приложение - это огромное (более 1000 страниц) приложение, и в первую очередь это прославленное приложение для ввода данных.Там нет крупного бизнес-процесса.Все большинство всех страниц имеют CRUD.Мы пытаемся реструктурировать все приложение от старой базы кода (C / C ++) - настольное приложение к веб-приложению.

Мы начали с Angular, но с ограниченным знанием Javascript, это былокрутая кривая обучения.К вашему сведению: все наши разработчики знают C #.Нам очень трудно привлечь новых разработчиков в мир Angular / Javascript.

При всем этом я изучал ASP .Net Core + Razor Pages и обнаружил, что переход легче по сравнению с Angular.Вот преимущества, которые я видел до сих пор:

1. Обрабатывать C # POCO в HTML для связывания.Нет необходимости конвертировать в POCO на основе TS.
2. Проверка на уровне модели с использованием аннотаций данных
3. Маршрутизация по умолчанию или настраиваемая маршрутизация на уровне API.Одно место для определения маршрутизации.
4. Минимальное использование JavaScript.К вашему сведению: Попытка также использовать WebAssembly.Мы также изучаем Blazor

Так как это система ввода данных, делает рендеринг на стороне клиента по сравнению с рендерингом на стороне сервера, имеет большое значение?

Есть ли лучшее преимущество в выборе Angular с .Net Core?Веб-API поверх ASP .Net Core 2 + Razor Pages?

Answer 1

Это очень взвешенный вопрос, но в целом одностраничные приложения требуют усилий на несколько порядков больше, чем страницы, отображаемые сервером.Вам придется продублировать логику в C # бэкэнде и во внешнем интерфейсе typecirpt.Вам придется иметь дело с множеством ошибок, когда вы кодируете интерфейс на не типобезопасном динамическом языке, который имеет сомнительные конструкции.В конце концов, одностраничные приложения того стоят, потому что они обеспечивают богатый и увлекательный опыт для конечного пользователя, если все сделано правильно.Но попасть туда - тяжелая битва.

Учитывая опыт ваших разработчиков, я бы рекомендовал делать это в Razor Pages или MVC и постепенно вводить биты кода Angular / React в области внешнего интерфейса, требующие улучшений.

В другихслова, делайте все это в Razor Pages / MVC, выбирайте небольшую область, разветвляйте промежуточный конвейер и обслуживайте небольшое приложение Angular.

Answer 2

Для начала я бы посоветовал вам использовать серверное SPA-приложение Blazor.

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

SPA похож на настольные приложения по своему дизайну И это наиболее подходит для использования с формами ввода данных Я полагаю, ваша команда состоит из разработчиков настольных приложений (WinForms, WPF), и они легко начнут разрабатывать, как только постигнут Компонентную модель, на которой основан Blazor или любая другая инфраструктура SPA.

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

• Ваши разработчики хорошо знакомы с C # и плохо знают JavaScript
• Кривая изучения JavaScript + SPA-фреймворка, такого как Angular, намного выше, чем Blazor, знаете ли вы JavaScript или нет.

Примечание. Здесь следует подчеркнуть, что для разработки приложений Blazor требуются некоторые инвестиции в обучение, хотя и не такие высокие, как, например, в Angular, даже если вы опытный разработчик Razor Pages или MVC. Также обратите внимание: Знание C # (языка) не отражает Знание (Asp) .Net Core Framework.

• Shared Libraries: это один из факторов, почему стоит использовать Blazor. В Blazor вы можете создавать проекты для совместного использования на клиенте и сервере. Например, вы можете создать свою модель в общем проекте и использовать ее с обеих сторон.

Зачем использовать серверную часть Blazor

Серверная часть Blazor наиболее подходит для корпоративных приложений, работающих в частной сети.

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

Таким образом, вы действительно можете создать быстрое и надежное приложение, похожее на настольное.

Надеюсь, это поможет ...

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

Answer 3

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

Используйте Visual Studio + ASP.NET core + EF Core, чтобы автоматически преобразовать базу данных в модели и контекст базы данных. Затем автоматически генерировать (создавать) контроллеры и представления для всех операций CRUD. Посыпать дополнительные аннотации данных, где это необходимо.

И там, где вам нужно более сложное отображение / взаимодействие с данными (например, Grid, Calendar, ...), рассмотрите сторонние виджеты Javascript. Они не требуют опыта JavaScript.

Answer 4

Зависит от ваших потребностей.Ваша компания полна разработчиков на C #, так что переход на Angular увеличит время и сложность проекта.Кроме того, поскольку это веб-приложение, предназначенное для ввода данных в корпоративной среде, вам не нужно столько времени загрузки и оптимизации, сколько в коммерческом приложении.Обычно старайтесь разрабатывать, используя среду ASP.NET Core с бритвой, и попробуйте перейти на угловой проект с меньшим проектом.Это моё мнение.Вы хотите предоставить техническое решение, соответствующее потребностям вашей компании, и снизить затраты на разработку, это должно быть главной осью, которую вы выбираете.