在 asp.net-mvc 中引用特定于局部视图的 javascript 的最佳做法是什么？答案

【问题标题】：What is the best practice for referencing javascript that is specific to a PartialView in asp.net-mvc?在 asp.net-mvc 中引用特定于局部视图的 javascript 的最佳做法是什么？
【发布时间】：2014-04-22 13:42:18
【问题描述】：

我有一个 asp.nset-mvc 站点，我有一个局部视图，它存在于许多不同的视图中。

还有一个 .js 文件与该局部视图使用的功能相关联。

现在，我在每个父视图中都包含该 js 文件，该父视图在 head 部分中包含此部分视图。

我现在想通过从每个父视图中删除对 javascript 文件的引用并将该引用放在局部视图的主体中来更容易维护。（所以它只是在一个地方列出）

有没有人认为这种变化有任何不利之处？这是仅由特定部分视图利用的 javascript 的推荐做法吗？

【问题讨论】：

为什么不将所有的 JS 捆绑在一个文件中，完全避免这个问题？
我不明白你的评论。 js 都在一个 .js 文件中。我只是想确定引用该 js 文件的最佳实践（从每个父视图或部分视图内部）
这正是您要查找的内容：[在部分视图中包含 JavaScript 文件][1] [1]：stackoverflow.com/questions/912755/…
@leora，您是在询问任何特定的 mvc 框架版本吗？
放在局部视图中就可以了。最好把一起变化的东西放在一起。

标签： javascript jquery asp.net-mvc

【解决方案1】：

我会问自己几个问题：

js 文件有多大？它缩小了多少？
它在您的应用程序中平均使用了多少次？

如果它是一个不经常使用的大文件，我会将脚本包含在文件中而不做任何交易。

需要记住js文件是缓存的，如果一般用户会进入局部视图，就需要下载脚本。

关于脚本\样式处理的良好做法：

使用组合的 js 文件并在生产中缩小它们。
这可以通过使用资产管理器或使用捆绑包“分组”js文件来完成。

Bundles
Cassette - For Assets

你也可以使用“require.js”来加载依赖脚本。
我没用过，但据我所知，你可以设置依赖于其他模块和js文件的模块和js函数。

RequireJS

【讨论】：

【解决方案2】：

在我看来，你最好把它和你的其他脚本放在一起。

您应该捆绑、缩小和“永久缓存”脚本。如果您这样做，那么即使是您网站的新用户也只需下载一个小文件。通过将其分解为多个文件，您只会伤害事情。他们最好一次下载您网站所需的所有内容。

如果您的网站有很多不同的部分，而您不希望用户跨越这些部分，我会考虑使用单独的捆绑包。例如，也许您的未经身份验证的部分和您的“仅限会员”部分。即便如此，它也不会产生太大的影响，因此将它们以一种对您网站的整体架构有意义的方式捆绑起来可能更有意义（例如，可能仅限成员的部分是不同的 mvc 区域）。

但是仅仅因为不是每个页面都会使用它而将部分单独需要的脚本拉出来会适得其反。

编辑：我想我重新阅读后理解得更好。我所说的仍然有效，但强调捆绑。不要只在每个需要它的页面上包含所有脚本的单个脚本引用。最好基本上捆绑您的网站需要的所有脚本并将它们包含在每个页面上。使用缓存，用户只需下载一次，然后在浏览您的网站时不再发出进一步的脚本请求，而不是每个页面都以另一个需要下载的唯一脚本结尾。

【讨论】：

【解决方案3】：

我认为一个很好的解决方案是创建扩展方法以在 partialView 中添加 javascript

一个很好的例子：How to render a Section in a Partial View in MVC3?

【讨论】：

【解决方案4】：

你的问题的答案可以从这个问题的答案中得出：

您认为这个局部视图是整个 Web 应用程序的一部分，还是只是一个单独的组件？

通常，它是 Web 应用程序的一部分，因为您只会在此 Web 应用程序中使用它。因此，从这个角度来看，没有必要将视图与其 javascript 捆绑在一起，因为 javascript 以及视图无论如何都是 Web 应用程序整体的一部分。

我们什么时候捆绑东西？

当它们彼此相关且与整体之外的任何其他事物无关时。我怀疑您用于此视图的 javascript 不依赖于它之外的任何其他内容。甚至没有 jQuery？甚至没有任何类型的框架，例如淘汰赛还是 bob.js？如果是，那你为什么不把你的视图也和那些框架捆绑在一起呢？

是的，答案是——依赖。一个是实现，其他是依赖项。但是，当在一个 Web 应用程序中使用部分视图时，实现和依赖项之间的边界变得模糊。原因是，局部视图是 Web 应用程序的一部分。这只是一个框架的处理方式，让您以可重用的方式分离部分视图。但是局部视图仍然是整个 Web 应用程序的一部分，因此它的实现脚本也是如此。

如果您遵循所有这些想法，那么您会同意，在这种特殊情况下，您是想将代码与局部视图捆绑在一起，还是将其与 Web 应用程序的其余部分捆绑在一起并不重要。脚本。 完全一样。

因此，该决定必须由其他指标决定，例如脚本加载性能等。这超出了问题的范围，但提供的描述应该足以作为答案。

【讨论】：

【解决方案5】：

通过将引用放在局部视图的主体内来临时加载javascript是一种正确的策略。您可以避免在所有其他页面上解析和解释开销。即使您的 javascript 文件已被缓存，在包含它的每个页面上执行仍需要时间（尽管微不足道）。如果你有复杂的逻辑，或者迭代 DOM，或者你有很多这样的文件怎么办？..

真的，这是成熟的依赖管理的第一步。如果您知道在哪个页面上使用了哪些功能，那么将来任何重构或维护工作的成本都会降低。

问题是如何从局部视图中引用 javascript 资源。您不想只在页面中间转储<script> 标签^{[需要引用]}，而是可以使用像cassette 这样的专业资产管理器。有numerous perks 可以使用它，但首先你可以在页面生命周期的一个地方引用资产（例如，从你的局部视图）：

@{
  Bundles.Reference("scripts/your-dependency.js");
  Bundles.Reference("scripts/another-dependency.js");
}

...然后在其他地方渲染所需的<script> 标签（例如在您的主视图中）：

<body>
  ...
</body>
  @Bundles.RenderScripts()
</html>

...可能包括其他视图所需的额外资源和/或包含共享 javascript 代码的缩小包。

【讨论】：

【解决方案6】：

我使用类似于这里解释的东西，效果很好。 http://blog.mariusschulz.com/2013/07/07/generating-external-javascript-files-using-partial-razor-views

【讨论】：

【解决方案7】：

我认为你应该使用 requirejs 因为

在我看来，有三个比较重要的原因：

您可以在不污染全局命名空间的情况下创建和重用模块。全局命名空间污染越严重，函数/变量冲突的可能性就越大。这意味着您定义了一个名为“foo”的函数，而另一个开发人员定义了函数“foo”=其中一个函数被覆盖。

您可以将代码构建到单独的文件夹和文件中，并且 requirejs 会在需要时异步加载它们，因此一切正常。

您可以为生产而构建。 RequireJS 带有自己的构建工具，称为 R.JS，它将把你的 javascript 模块连接和 uglify 成一个（或多个）包。这将提高您的页面速度，因为用户将不得不进行更少的脚本调用并加载更少的内容（因为您的 JS 被丑化了）。

您可以看看这个简单的演示项目：http://bit.ly/requirejs（在 cloud9ide 中）。

要将您的模块构建到单个应用程序中，您只需安装 requirejs npm 包并运行命令：r.js -o build/build.properties.js

在开发过程中，将所有模块放在单独的文件中只是构建和管理代码的好方法。它还可以帮助您进行调试（例如，“Module.js 第 17 行”而不是“scripts.js 第 5373 行”上的错误）。

对于生产，您应该使用构建工具将 javascript 连接和 uglify 到单个文件中。当您发出更少的请求时，这将有助于更快地加载页面。您提出的每个加载请求都会减慢您的页面速度。你的页面越慢，谷歌给你的分数就越少。页面越慢，您的用户就会越沮丧。您的页面越慢，您获得的销售额就越少。

如果您想了解更多关于网页性能的信息，请查看http://developer.yahoo.com/performance/rules.html

【讨论】：