从ASP.NET MVC部分视图构建SPA - 这是一个好主意吗？

Question

我花了相当多的时间在React和Redux上享受它，但有时它对于具有大量CRUD的业务应用程序感觉有点过分，但在浏览器中没有大量的状态。< / p>

我想知道我是否可以使用单个容器元素在ASP.NET MVC中创建SPA，然后在用户导航时将不同的部分视图交换进出，从而为我提供整个页面的良好行为重新加载并允许我在Visual Studio中使用所有有用的脚手架，工具和代码优先数据库生成，也不必在JS和C＃中编写所有验证逻辑（如果使用连接到的SPA，我会这样做） Web API后端）。最初的一些初步实验似乎表明这是可行的。

显然，我不是第一个有这个想法的人，Dino Esposito在Visual Studio Magazine网站（Simplifying Single-Page Applications with ASP.NET MVC Partial Views和Integrating Updates, Deletes and Inserts with TypeScript and ASP.NET MVC）的两篇文章中对其进行了描述，并在{{3 }}。 John Fazzaro还解释了一种路由Revisiting Partial View Rendering in ASP.NET MVC的方法。

编辑： 我将集中这个问题来阻止它过于宽泛。在我的情况下，我并不那么担心网络流量，因为这些业务应用程序是定制的内部系统，用户相对较少。在这些情况下，开发时间比可能出现的任何可能的基础设施成本更昂贵。

所以，一些具体的问题：

1. 这种做法是否有任何明显的危险信号 真是个坏主意？
2. 有没有人在制作过程中这样做过，如果有的话，那是怎么回事 保持？随着应用程序越来越大，你受苦了吗？
3. 如果我们使用VS工具，这种方法会更快 开发比编写Web API后端和Redux / React客户端？
4. 我们是否会通过重复交换部分视图来创建内存泄漏 出来？

Answer 1

这种方法的主要问题是您发送的是潜在的大型HTML响应，而不是纯JSON / XML /其他数据。这种情况无视这一点，因为你仍然有大量的网络流量，减慢了速度，需要为每种不同的数据表示提供不同的局部视图......

这不是一个坏主意，它只是框架的主要优点是你可以定义1个后端API（例如发送小JSON），然后在多个页面上根据需要呈现不同的HTML。这意味着要测试的东西越少，网络流量越少（服务器负载也越少）。

一个好的中间方法是使用MVC或WebAPI来提供JSON API，然后使用较小的框架（如backbone或knockout）将其呈现为html模板。