带有剃刀页面的.Net核心与用于UI的Angular
我们的企业应用程序是一个庞大的(1000+页面)应用程序，它主要是美化的数据输入应用程序。没有主要的业务流程。几乎所有的页面都有CRUD。我们正在尝试重新构建整个应用程序，从一个旧的代码库(C/C++) -桌面应用程序到基于web的应用程序。
我们从Angular开始，但由于对Javascript一无所知，这是一个陡峭的学习曲线。仅供参考:我们所有的开发人员都知道C#。我们发现很难让新的开发人员进入Angular/Javascript的世界。
尽管如此，我研究了ASP + .Net页面，发现与Angular相比，它更容易过渡。到目前为止，我看到了以下优势：
- 处理HTML内的C# POCO进行绑定。无需转换为基于TS的POCO。使用data annotations
- Default路由或应用编程接口级别的自定义路由进行
- 模型级验证。一个定义路由的位置。
- 最小JavaScript使用量。仅供参考:也尝试使用WebAssembly。我们还在调查Blazor
既然它是一个数据输入系统，那么客户端渲染与服务器端渲染有什么关系呢？
与.Net核心2+ Razor页面相比，选择带有.Net核心Web API的Angular有更好的优势吗？
回答 6
Stack Overflow用户
发布于 2019-06-03 17:36:47
从最后开始，我建议您使用Blazor服务器端SPA应用程序。
为什么使用SPA
SPA在设计上类似于桌面应用程序，它最适合用于数据输入表单我猜你的团队是由桌面应用程序(WinForms，WPF)开发人员组成的，一旦他们理解了Blazor或任何其他SPA框架所基于的组件模型，他们就会很容易开始开发。
为什么使用Blazor
- 您的开发人员对C#非常熟悉，但对JavaScript + SPA框架的JavaScript
- 学习曲线了解较少，例如Angular比Blazor要高得多，不管您是否了解JavaScript。
注意:这里必须强调的是，开发Blazor应用程序的能力需要一些学习投资，尽管不像Angular那样高，即使您是经验丰富的Razor页面或MVC开发人员也是如此。另请注意: C# (语言)知识并不反映(Asp).Net核心框架的知识。
Blazor共享库:这是使用的原因之一。在Blazor中，您可以创建可在客户端和服务器上共享的项目。例如，您可以在共享项目中创建模型，并在两端使用它。
为什么使用Blazor服务器端
Blazor服务器端最适合内网运行的企业应用。
- 所有资源都在您的控制之下
- 您不必使用web请求。您可以使用直接或通过存储库访问数据库的服务。
- 与公共服务器端Blazor、专用服务器端Blazor不同，尤其是针对您公司的Blazor，它不太可能导致任何有意义的网络延迟。
你可以通过这种方式创建快速、健壮、类似桌面的应用程序
希望这能帮到你。
注意:我还没有完成我的回答，我会不时更新它。请不要犹豫，问任何你想要的问题。
Stack Overflow用户
发布于 2019-06-03 14:24:05
这是一个非常固执己见的问题，但一般来说，单页面应用程序所需的工作量要比服务器呈现的页面大几个数量级。您必须在C#后端和typescript前端复制逻辑。当你用一种非类型安全的动态语言编写前端代码时，你将不得不处理大量的bug，这种动态语言的结构有争议。最后，单页面应用程序是值得的，因为如果处理得当，它们为最终用户提供了丰富的、引人入胜的体验。但实现这一目标是一场艰苦的战斗。
考虑到您的开发人员的经验，我建议您在Razor Pages或MVC中这样做，并逐步在需要增强的前端区域引入一些Angular/React代码。
换句话说，在Razor Pages/MVC中完成所有工作，选择一小块区域，分支中间件管道，并为一个小的Angular应用程序提供服务。
Stack Overflow用户
发布于 2019-06-04 03:07:08
因为你的大多数应用都是简单的CRUD，所以可以考虑只使用razor/MVC。
使用Visual Studio + ASP.NET核心+ EF核心自动将数据库逆向工程到模型和数据库上下文中。然后自动生成(搭建)所有CRUD操作的控制器和视图。在需要的地方添加额外的数据注释。
以及需要更高级数据显示/交互的地方(例如，网格、日历等)考虑一下第三方Javascript小部件。他们不需要JavaScript的专业知识。
https://stackoverflow.com/questions/56421919
复制相似问题