1

使用 Knockout 组件 + Asp.Net MVC 时，以下代码段是一个好习惯吗？我可能缺少的任何缺点？

基本上是通过使用 Razor 服务器端渲染注入部分 ko 组件依赖项（主要是初始数据）...

代码片段：

<my-component params="{ 
    foo: '@Model.FooProperty',
    bar: '@Model.BarProperty',
    baz: @Json.Encode(@Model.SomeArray)
}"> </my-component>

编辑：

为了避免@Quango 指出的字符串转义问题，我实现了这个助手：

public static stringEscapeString(this HtmlHelper helper, string value)
{
   return HttpUtility.JavaScriptStringEncode(value, true);
}

用法：

<my-component params="{ 
        foo: '@Html.EscapeString(Model.FooString)', ...
4

1 回答 1

0

在我的工作中，我们在一个 ASP.NET MVC 项目中使用了 Knockout，并且确实考虑了这种不好的做法。但其原因可能不适用于您。这是你必须自己判断的事情

  • 不缓存 HTML（因为注入的值可能会改变）
  • 没有将您的 HTML 与您的 JavaScript 捆绑在一起（同上）
  • 为同一个问题混合不同的解决方案可能是一种不好的做法，尤其是在（大型）团队中。本质上，您选择了 Knockout，因此“正常”的做法是在 JavaScript 中获取您需要的任何数据，并在您的视图中绑定到它。如果这是您通常所做的，请考虑您是否真的想在这里创建一个异常，只是因为数据是（假定的）静态的。如果这只是为了节省几个字节，那么想象一下平衡它以在一个缩小的包中提供所有 HTML 和 JavaScript，这也可以缓存在客户端上。
  • 以后无法覆盖数据，它本质上是由服务器“硬编码”的。
  • 您的代码变得不那么可移植了。您的 Razor 语法本质上将您的前端与您选择的后端技术相结合。如果这是一个长期项目，请考虑是否有可能在几年后，您可能会决定另一种后端技术可能是更好的选择，如果您必须重写一半确实有意义前端只是为了使这成为可能。

这些原因都与所有项目无关，因此在很大程度上取决于上下文。我试图列出我能想到的尽可能多的缺点。

于 2016-02-05T12:42:17.640 回答