c# - MVC 对 ViewPage 本身强类型化

Question

我看到很多关于强类型化 View 模型数据的帖子。

我对以某种方式强类型化 View 本身感兴趣。

我担心，如果 View 的模型类型发生变化，或者 View 本身的名称/位置发生变化，返回 View(xyz) 的 Controller 操作可能会在运行时崩溃。在我看来，MVC 框架的松散耦合在这个特定领域中走得太远，在 RAD 环境中变得适得其反。 (没有立即收到重大更改的通知)

如果 View() 调用由于缺少 .cshtml 文件或无法映射的模型类型而无效，是否有办法触发编译时错误？

Answer 1

本次讨论是关于对象的早期绑定(bind)和后期绑定(bind)以及每种场景的固有优势。

早期绑定(bind)对象在编译时已知，但必须是有限集。它们不会产生与它们不存在相关的运行时错误，因为它们不能丢失，但是该集合是有限且不可变的。

后期绑定(bind)对象在编译时是未知的 - 相反，它们在运行时是已知的，并且理论上可以是无限集。后期绑定(bind)对象通常表示非常量 - 在应用程序运行时发生变化的事物。例如，像 Unity 或 Ninject 这样的依赖注入(inject)框架将从配置文件进行后期绑定(bind)，以允许您注入(inject)几乎任何对象。如果 Unity 或 Ninject 要在编译时验证注入(inject)的对象，则意味着这些对象是早期绑定(bind)的，并且框架必须了解要解析的所有可能类型...如果您引入了新类型，您需要重新编译框架才能接受它!

简而言之，后期绑定(bind)提供了适应未知情况的灵活性...例如您的 MVC View ，微软在发布框架时并不知道这些。

MVC View 后期绑定(bind)的原因是它们不是一组固定的事物。相反，它们在运行时受到许多来源(例如文件系统和内存对象)的绑定(bind)，并且每个人的 MVC 项目都会有不同的 View 。如果 MVC 要在编译时验证 View ，则它必须在执行之前了解整个 View 集。编译器将验证文件是否存在(在项目中正确引用)，但不会验证 Controller 的 ViewResults 是否正确引用这些文件。这样做的原因是它使您能够做很多事情，包括动态地提供 View /数据。并非所有 View 都来自磁盘...例如，没有什么可以阻止您从字节的 MemoryStream 返回 FileResult。再举一个例子，您可以将整套 View 存储在数据库中，并安装自定义 ViewEngine 来直接从数据库记录进行渲染。

ViewResult 还支持其他不基于文件的数据类型，例如返回二进制序列(图像或文件)、XML、JSON 等。 JSON 通常是在运行时从内存中的对象创建的，因此编译时验证没有用。

文件 I/O 也很慢，并且 View 通常在初始加载后缓存在内存中。如果应用程序必须在编译时知道它在内存中缓存什么，那么缓存将不会非常灵活或有用。

所以最终不行，没有简单的方法可以做到这一点。您可以编写一些不适合单元测试的单元测试:它们将执行每个 Controller ActionMethods，然后调用 ViewEngine 来呈现 View 并捕获任何文件未找到错误。这大约是您无需付出大量努力就能达到的最接近结果。

您可以预编译 View ，以使 View 中的错误成为编译时错误。默认情况下，当您的 MVC 应用程序运行并首次访问 View 时， View 将被 JIT(即时编译)。如果修改.csproj直接在记事本或其他文本编辑器中打开文件，您将看到 <MvcBuildViews>设置为false - 只需将其设置为 true但要知道这会增加编译时间。