我正在使用 Ember 将一个好的旧 ASP.Net 网站转换为单页应用程序.js在一个 ASP.NET Web API 项目中。我团队和我自己的所有开发人员都是javascript的新手。我们花了最后两周的时间学习基础并比较SPA框架。如果我的问题听起来很愚蠢，我提前道歉:)
到目前为止，我找到的所有 Ember 教程都将所有 Handlebars 模板包含在一个文件中。我认为在时机成熟时将它们拆分为单独的文件 （*.hbs） 会很明显，但事实并非如此。我可能在这里完全错过了一些东西，但我找到了大约 4 种方法可以在我需要时取回我的模板。我想知道您会推荐哪种方法：
-
连接，然后在应用加载时注入所有模板文件。我可以在服务器端编写一些 C# 代码，在应用程序加载时（即每次访问者进入应用程序时）将所有模板文件连接成一个模板文件。就处理而言，这对我来说似乎很奇怪，但也因为生成的HTML文件会很重。
-
当我需要时，通过 Ajax 动态加载每个模板。几乎是这里所做的。我有点喜欢这个解决方案，即使我还没有尝试过。对我来说，在需要时异步获取模板而不是在第一次加载时加载整个应用程序是有意义的。
-
使用 MVC Asp.Net 捆绑机制。我找到了像csharp-ember-handlebars这样的东西来预编译服务器端的模板，并将它们作为单个javascript文件返回。它可以工作，但我觉得当我添加新模板时，预编译文件会变得非常重。
-
将 Grunt 与插件 grunt-ember-handlebars 一起使用来预编译模板。我不熟悉 Grunt，但如果我理解得很好，所有从事该项目的开发人员都必须安装 Node.js + Grunt + 学习如何使用命令提示符 + 记住在每次提交之前运行命令（如果他们修改了模板）。这对网页设计师来说并不明显。将 grunt 添加到构建操作中将需要整个开发团队（处理其他项目）在他们的机器上安装咕噜声（不可接受）。
我需要找到一个简单而优雅的解决方案来解决这个问题。我的项目与其他 35 个项目在一个解决方案中，我不能给构建增加太多的复杂性，也不能依赖不稳定的库。也许当我认为我可以在我的项目中使用 Ember 时，我太乐观了。任何建议将受到欢迎！
您的 #3 是我见过的应用程序处理模板的最理想（也是最常见的）方式。 使用编译和缩小的模板文件，您真的不必担心添加新模板方面的性能问题，尤其是在利用缓存的情况下。
编译模板并立即可用的一个好处是，用户只需下载一次™资源，就像为每个后续页面加载下载资源一样。 这带来了出色的用户体验。