14

我想知道为什么不只是在使用 jQuery+jQuery 模板+KnockoutJS 组合的 ASP.Net MVC 4 Web 项目中使用基于 REST 的静态 HTML 文件(托管在 Azure 上并使用 ACS 保护的 ASP.Net MVC 4 WEB API)。Web API 可以使用实体框架并返回可以使用 $.ajax() 检索并使用 KnockoutJS 绑定的 JSON 序列化对象。

ASP.Net MVC(用于 Web 页面)提供了什么来为这种架构增加价值?
在我的头上,我能想到:

  1. 多设备支持(设备检测和模板替换)
  2. 提交数据的服务器端验证(不确定我是否也可以将验证放在 WEB API 上?)
  3. 即使我使用的是静态 html 文件,我仍然可以重写我的 URL(因为无论如何我都在使用 ASP.Net MVC)。

有人可以帮助我更好地理解这一点吗?提前致谢。

4

5 回答 5

7

好问题。我当然发现随着我的 Knockout 项目的进展,我的 MVC / Razor 代码变得越来越少,但我认为我将始终拥有我想要在服务器端确定的视图的某些方面。

基本的上下文内容,例如是否在布局页面中呈现登录/注销面板,与角色相关的决定应该访问什么等。我想如果您对安全性足够小心并在服务器上实施足够的保护代码有人实际上尝试做某事,然后您可以在 Knockout 中实现大部分内容,但您最终可能会出现大量臃肿,以适应视图的每一个可能部分。

这可能取决于您的应用程序,但我认为对于大多数 Web 应用程序而言,在服务器渲染时应确定的内容与应在客户端完成的内容之间存在相当普遍的区别。

如果不出意外,您可能希望您的视图中的链接等被搜索引擎索引。例如,如果您以 JSON 格式传递您的“最新 10 种产品”,并在 Knockout 模板中使用超链接呈现它们,那么您将失去这一点。

于 2012-08-14T23:11:09.670 回答
3

这确实是一个使用正确工具来完成工作的问题。

从我在使用淘汰赛进行开发后可以看出,它的真正力量来自可观察对象和实时 DOM 更新。这使得客户端应用程序中的丰富界面可以更快地创建,并且更易于管理。但是,与直接使用 Razor 页面相比,它仍然更耗时且难以实现。因此,Knockout JS 对于某些应用程序来说是一个优势,在这些应用程序中,大量数据驱动的 UI 更新需要“ajaxically”发生,但对于其他应用程序来说就太过分了。

于 2012-08-15T02:44:06.883 回答
1

如果客户在这种情况下没有启用 Javascript,您的网站将毫无用处,您将无法为他们提供合适的替代方案。

使用 MVC 框架和 Razor 语法,您仍然可以构建动态生成的、数据驱动的内容,而无需使用 jQuery 或 AJAX。无论您是否启用了 Javascript,MVC 都会为您提供模型和视图之间的关注点的清晰分离。

于 2012-08-14T19:40:11.540 回答
1

安全性可能是我看到的第一大优势。您仍然拥有其背后的结构 ASP.NET。是的,确实如此,在您的视图中,您当然可以使用 razor 语法并使用 Knockout 呈现您的视图模型,而 JSON.NET 使数据绑定比以往任何时候都更容易。最终在未来,也许 MVC 不会成为未来等式的一部分?(也可以查看 Meteor js,它非常酷,而且除了 javascript atm 之外这种类型的动态模型绑定是不可能的。)

另外,如果您想看到它的实际效果,我发现了一个带有 MVC 和淘汰赛的优秀 Codeproject。http://www.codeproject.com/Articles/424642/Customer-KnockoutJS-and-MVC-demo-using-JSON

于 2012-08-14T20:00:03.760 回答
1

在这里,阅读这个。引用它:

围绕整个页面加载构建 Web 应用程序然后“逐步增强”它们以使其行为更加动态已经不够好。构建快速、响应迅速和现代的应用程序需要您完全重新考虑您的方法。

至于您的问题,MVC 提供了什么可以为 MVVM 架构增加价值?为不同的设备提供自定义内容可能是一个优势,但您也可以通过 CSS 媒体查询在一定程度上做到这一点。决定取决于您希望从服务器发送多少字节到设备。

您也可以在不使用 MVC 或 WebAPI 的情况下进行服务器端验证,并且不需要使用 ModelBinder 或 ModelState.IsValid 来执行此操作。研究一下 FluentValidation.NET 之类的东西,它允许您在服务器上进行高度复杂的输入验证,甚至是 Web/HTTP 层的下一层。当然,您还想使用 jQuery validate 之类的东西来验证客户端。

我同意这里的其他答案,即在服务器(控制器操作或剃刀)级别做一些安全级别的事情会更容易一些,而且更“值得信赖”。但是这里没有其他人提到 MVVM 的可测试性。围绕控制器操作或其他服务器端代码编写单元测试非常容易。这并不是说你不能单元/集成/UAT 测试 MVVM 应用程序,只是它需要更多的努力 IMO。

于 2012-08-15T13:09:48.607 回答