我正在使用 ASP .NET 3.5 并寻找一种方法来捆绑我的一堆脚本。我遇到了 ScriptManager 的 CompositeScript 元素。这是用于捆绑的好方法吗？它有任何后果吗？
问问题
2325 次
2 回答
2
优点和缺点，陷阱与其他脚本捆绑解决方案类似——您首先要最小化，注意脚本的顺序，以 ; 开头的脚本 关闭另一个文件中的任何未关闭的脚本。
一个 ASP.NET 特定问题是调试/开发体验。如果你结合你的脚本，在 IE 调试器中找到你的代码要困难得多，脚本将有一个机器生成的名称，看起来类似于其他框架生成的脚本，你的代码将被埋在一个更大的文件中。
所以我在后面的代码中注册我的引用并将它们包装在 ifdef DEBUG/endif 和 ifdef RELEASE/endif 中（请务必在项目属性中定义 RELEASE，如果使用此技巧，默认情况下不会发生）。在 RELEASE 版本中，我捆绑了所有脚本，而 DEBUG 版本将文件分开。
同样根据 Microsoft 的建议，脚本捆绑最适合您在整个网站上需要的文件。如果您有一个包含 A、B、C 的多页站点，并且您的用户通常只访问其中一个，那么捆绑 A、B、C 的文件将为用户提供 2 个额外文件。我认为这是一个糟糕的微优化，因为大多数应用程序都有小的 javascript 文件和大的库，所以一个网站的 JS 捆绑价值不足以担心字节数，除非你有很多流量。
最后，服务器端 ScriptManager 不提供任何方式来延迟脚本或从客户端动态触发加载（除了在 UI 之后加载脚本），我使用 LAB.js 稍后动态加载脚本......这有时可以允许你推迟一个脚本，直到你知道你需要它，并且可能永远推迟加载该脚本。一旦您捆绑了该脚本，它将为每个用户加载，无论他们是否需要它。
第 2 部分 另一个问题，至少对我来说是，虽然您可以在 web.config 中启用 JS 文件的缓存（目前没有时间查找语法！），您还可以使用 expires 标头在 IIS 级别启用缓存，当新版本出现时，ScriptManager 不会帮助您“破坏”缓存。理想情况下，脚本管理工具会诱使浏览器认为脚本位于随上次更新更改而更改的文件夹中，因此脚本可以在客户端缓存一年。
我希望我有关于脚本是否被服务器端缓存的信息——我猜他们不是。但是因为用户通常最多每天获取一次脚本——在我的服务器上，它们似乎缓存了 24 小时，所以如果在每个请求上重新生成脚本就不太有趣了。
最后，如果您将 CDN 用于 jquery 之类的东西，（取决于您是公共网络还是 Intranet），4.0 和 4.5 版本可以更容易地告诉 ScriptManager 使用 CDN 并在 CDN 关闭时回退.
于 2013-05-13T17:53:12.893 回答
0
使用 sumfile.js?n={0}
其中 {0} 是您所在建筑物的编号
于 2014-07-21T06:46:55.463 回答