5

我最近一直在进行一些讨论，讨论是关于转移到 ASP.NET MVC 和 Knockout 以在当前是 ASP.NET Web 表单的产品上进行未来工作。该产品具有 SPA 的一般当前定义的许多特征。

当您开始使用 JS 视图模型生成所有视图时，我从未完全了解 MVC 是如何真正适合的，这些视图模型从调用 JSON Web 服务中获取数据。

有没有利用 Knockout w/JS 模型和 JSON 以及 MVC 框架的最佳部分的“最佳位置”？

以下是我一直在考虑的一些事情（有点随机 - 只是看看我是否可以激发一些讨论/答案）：

  • 你什么时候会使用 Knockout vs. Razor？Knockout 在客户端浏览器上运行时生成视图元素。Razor 在客户端收到响应之前作为服务器请求的一部分运行。是否有时一个明显比另一个更好，还是归结为个人品味？
  • 为了完成代码，以 C#/Razor 为幌子保留更多代码是否有价值？此外，当抛出异常时，对已编译代码的堆栈跟踪似乎比 JS 调试更容易。
  • 通过创建一个空白的 ASP.NET 应用程序和一个独立的 Web API 项目，将视图与后端完全分离是否更好？
4

1 回答 1

5

很多很好的问题，我将分享我对这些主题的一些想法。（问题已转述）：

1) MVC 在 Knockout 世界中是否有一席之地？- 绝对地。MVC 不仅仅是 Razor。服务器端路由、区域、身份验证等都是由 MVC 提供的。所以在我看来，我仍然可以将 MVC 用于所有“管理员和组织”，但我的所有视图仍然主要（但不一定完全）由 AJAX 驱动。我之前讨论过在 SO 上一起使用 MVC 和 KO 。我在 WintellectNOW dot com 上也有专门针对该主题的视频。

2)我应该什么时候使用 Razor？- 让我们实际转换一下术语。这真的不是关于 Razor 与 Knockout：它实际上是关于服务器端与客户端渲染。那么什么时候应该使用服务器端渲染呢？一个理想的时间是当您加载只需要在页面初始化时完成一次的数据时。例如，如果您有一个用于下拉列表的状态列表，并且该列表极不可能更改，请继续将其加载到服务器端。在这种情况下，为什么要转身向 API 发出另一个请求呢？我会保留那些对动态或上下文敏感数据的调用。

3)在 C# 中保留更多代码用于工具目的是否有价值？- 恕我直言，不。调试 JS 确实很痛苦，但这不足以让我无视我在客户端可以做的所有令人敬畏的事情。偶尔为提供更好的用户体验而感到沮丧是值得的。

4)我是否应该将 Web API 移动到不同的项目以保持代码分离。- 这完全取决于项目的需要。如果 Web API 项目要为多个应用程序提供服务，那么是的，它应该在一个单独的项目中。这也将把它放在一个单独的 DOMAIN、SUB、PORT 或其他东西上，以将它与 Web 应用程序的其余部分区分开来。这样做会引入跨域资源共享 (CORS) 问题。CORS 是一个特别的地狱，除非绝对必要，否则我不会经历。如果您的 Web API 只为您的单个 Web 应用程序提供服务，请帮自己一个忙，并将其保留在同一个项目中。

与其他一切一样，这在很大程度上取决于个人喜好。我的是使用服务器端来管理我的应用程序的大局，以及所有 UI/UX 的客户端。

于 2013-10-27T13:18:00.947 回答