通过Razor向Knockout组件注入依赖项

Question

使用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)', ...

Answer 1

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

• 不缓存HTML（因为注入的值可能会更改）
• 不使用您的JavaScript捆绑您的HTML（与上述相同）
• 针对同一问题混合使用不同的解决方案可能是一种不好的做法，尤其是（大型）团队。从本质上讲，你已经选择了Knockout，所以正常情况下＆＃39;练习是获取JavaScript中所需的任何数据，并在视图中绑定它。如果这是你通常做的，考虑一下你是否真的想在这里创建一个例外，因为数据是（假设）是静态的。如果这就是保存几个字节的全部内容，那么只需设想将其平衡为在缩小的捆绑包中提供所有HTML和JavaScript，也可以在客户端上缓存。
• 以后无法覆盖数据，它基本上是硬编码的＆＃39;由服务器。
• 您的代码变得不那么便携了。您的Razor语法基本上将您的前端与您选择的后端技术相结合。如果这是一个长期项目，请考虑从现在开始的几年内，您可能会认为另一种后端技术可能是更好的替代方案，如果真的有意义，那么您是否有必要为了使这成为可能，重写前端的一半。

这些原因都不适用于所有项目，因此它在很大程度上取决于上下文。我试图列出尽可能多的可能的缺点。