Razor Generator：这是准确的吗？

Question

我最近询问了我目前工作地点的前首席开发人员，为什么他选择使用 Razor Generator 将我们的观点预编译成单独的组装。

他在下面提出了一些声明，但我似乎无法在网络上找到任何 Razor Generator 配置文件和/或指标来支持该声明（10-快 100 倍），和/或，如果 IIS7/ASP.NET 在幕后对预编译与运行时编译的视图及其优势或不足做了什么-那里的。

谁能指出我正确的方向？还是评论？

在我看来（就启动时间而言）只需为站点设置 IIS autostart = true 就可以平衡使用 Razor 生成器进行预编译的任何好处强>。这是他的声明：

为什么我们使用 Razor 生成器来预编译我们的视图以及为什么将它们放在单独的程序集中？

第一个是简单的编译时错误检查。有了这么多观点 这似乎是避免生产错误的好方法。有点 令人沮丧的是不得不重新编译才能看到我对视图的更改 承认，但（在我看来）完全值得知道你 预先进行更多的错误检查。

第二个是当视图没有在项目中编译时，它们 在运行时编译，然后那些编译的表示有 存储在内存中。有时，如果他们没有定期访问 （大多数观点都是这种情况，因为有这么多） 那些存储的编译版本被废弃并被垃圾收集到 节省内存。因此，除了网站中最常访问的视图之外，所有视图都像 每次访问 gaf.com 时都会重新编译。但如果 你把它们放在一个项目中，只需要加载编译的版本 如果它不在内存中，则来自 dll（是的代码可能是垃圾 也收集，但较少）。从 dll 加载是 10 - 100 快几倍（来自 Razor Generator 项目的网站 - 我 没有自己验证，但听起来很合理）。

Answer 1

我们遇到了同样的问题。我们开始编译 View 是为了发现在 集成测试 和 UX 测试 中可能会出现的明显问题。更糟糕的是不知何故潜入生产环境的错误。

但是，我们的构建时间变得无法忍受。我们的开发人员构建了无数次，这成为我们一天的主要部分。午饭后我们开玩笑说要测试，这样我们就可以在外出时完成构建。

我们最终在 UX-tests 之前开始构建。

---

现在我们正朝着预编译的方向前进。目前我们团队中只有一个人采用了它，并且显然预编译明显优于构建（增量与总）。设置基本上是一个 nuget 提取。

这些文章应该是一个好的开始

http://stacktoheap.com/blog/2013/01/19/precompiling-razor-views-in-asp-dot-net-mvc-3/

http://blog.davidebbo.com/2011/06/precompile-your-mvc-views-using.html

---

预编译为我们提供了部署现成二进制文件的所有优势。我们的用户不会在第一次点击视图时体验到瞬时延迟。

据我所知IIS autostart = true 将启动您的应用程序池，但不会强制编译您的视图。因此，您将获得第一个使用每个视图的用户的初始启动命中。