Mvc 4 单页应用程序视图导航到站点的不同部分

Question

我正在着手开发我的第一个 spa mvc 4 应用程序，我看过 Steve Sanderson 的演讲，这很棒，但他的最终交付跟踪器应用程序最终获得了 3 个视图，这些视图都在同一个视图页面中声明。这对于小型应用程序来说很好，但是当站点的不同部分具有不同的数据时，如何在更大范围内进行管理。我要构建的网站需要保留在一个页面上，因为我想保持一个类似于 Facebook 风格聊天的聊天窗口打开，并且我将使用 SignalR 在应用程序的固定部分中将数据推送到客户端。我是否只是使用@Ajax.actions 来加载我网站的完全不同的部分，就像我只是创建一个非 spa 网站一样？计划是在大部分时间将用户留在 I 站点的特定部分，但我希望设置页面和用户配置文件管理页面在单独的视图中定义。

任何好的示例代码都将不胜感激我打算只使用带有淘汰赛和 nav.js 的 bog 标准 spa，除非有人可以为 mvc/entity 框架提出更成熟的 spa 技术，它有一些很好的文档并且很受欢迎.

Answer 1

我所做的是可怜的 mans SPA，它基本上让我的网站像一个标准的 ASP.NET MVC 应用程序，所以我有多个视图、多个控制器和操作，并且我有一个带有容器 div 的 shell 页面，我使用它作为整个站点通过 Ajax 调用加载我的视图的容器，所以我有很多很多 jQuery ajax 调用，我在某种程度上尝试重构我的客户端 JS 并进行通用导航到 Javascript 方法（除其他外） ) 在我的 shell 页面中，然后我从子视图中调用它，因此单击特定子视图中的某个 ActionLink，我将调用我的通用 JS 页面加载器： GoToPage(controller, action, query) 它将使用 jQuery Ajax 将目标控制器/动作/视图加载到 shell.cshtml 中的容器 div 中。对于导航，我使用 Ben Alman 的 hashchange plugin 来检测哈希更改事件并将适当的视图加载到我的容器 div 中。这种方法有明显的缺点，因为您不是在构建一个真正的 SPA，而是在制作一个带有 SPA 外观的服务器端应用程序，实际上这与一个合适的 spa 之间的性能差异只从服务器获取数据（不是 HTML）有点明显，但是如果您是传统的 ASP.NET MVC 开发人员，这可以让您不必使用新的库，如 Sammy.js 和淘汰赛等。最大的缺点是您将编写大量重复的连线 javascript，这很快就会变得一团糟，尤其是当您有很多表单时。尽管您可以采取某些步骤来重构和重用通用代码。因此，总而言之，在服务器端生成视图并使用 Ajax 检索它们可能不是最佳的 SPA 解决方案，但对我来说，它的学习曲线最少（实际上没有哈哈）。我最近一直在看Durandal，我认为它最终为创建 SPA 提供了一个非常可行的解决方案，我特别喜欢与Sammy.js 不同的是，您不必在初始页面加载时加载所有视图，即使用户不会访问这些页面。 here 提供了一个不错的入门教程。