使用 Ember.js 和 ASP.NET MVC 管理大型 SPA 中的模板

Question

我在 ASP.NET Web API 项目中使用 Ember.js 将一个好的旧 ASP.Net 网站转换为单页应用程序。 我团队的所有开发人员和我自己都是 JavaScript 新手。我们在过去的两周里学习了基础并比较了 SPA 框架。如果我的问题听起来很愚蠢，我提前道歉:)

到目前为止，我发现的所有 Ember 教程都将所有 Handlebars 模板都包含在一个文件中。我认为时机成熟时将它们拆分为单独的文件 (*.hbs) 是很明显的，但事实并非如此。我可能在这里完全遗漏了一些东西，但我发现了大约 4 种方法可以在我需要模板时取回它们。我想知道您会推荐哪种方法：

1. 在应用加载时连接并注入所有模板文件。我可以在服务器端编写一些 C# 代码，在应用程序加载时（即每次访问者进入应用程序时）将所有模板文件连接成一个文件。就处理而言，这对我来说似乎很奇怪，但也因为生成的 HTML 文件会很重。

2. 在需要时通过 Ajax 动态加载每个模板。几乎完成了here。我有点喜欢这个解决方案，即使我还没有尝试过。对我来说，在需要时异步获取模板而不是在第一次加载时加载整个应用程序是有意义的。

3. 使用 Asp.Net MVC 的 Bundling 机制。我找到了像csharp-ember-handlebars 这样的东西来预编译服务器端的模板并将它们作为单个javascript文件返回。它可以正常工作，但我觉得当我添加新模板时，预编译的文件会变得很重。

4. 使用 Grunt 和插件 grunt-ember-handlebars 来预编译模板。我对 Grunt 不熟悉，但如果我理解得很好，所有从事该项目的开发人员都必须安装 Node.js + Grunt + 学习如何使用命令提示符 + 记得在每次提交之前运行命令（如果他们修改了模板）。这对网页设计师来说并不明显。在构建操作中添加 grunt 将需要整个开发团队（从事其他项目）在他们的机器上进行 grunt（不可接受）。

我需要找到一个简单而优雅的解决方案来解决这个问题。我的项目包含 35 个其他项目的解决方案，我不能为构建增加太多复杂性，也不依赖于不稳定的库。也许当我认为我可以将 Ember 用于我的项目时，我过于乐观了。欢迎提出任何建议！

Answer 1

您的#3 是我见过的应用程序处理模板的最理想（也是最常见）的方式。使用经过编译和缩小的模板文件，您真的不必担心添加新模板时的性能问题，尤其是在您利用缓存的情况下。

编译模板并立即可用的一个好处是，用户只需下载您的资源一次™，而不是为每个后续页面加载下载资源。这会带来出色的用户体验。