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)提供了灵 active 以适应未知...例如您的 MVC View ，Microsoft 在发布框架时还不知道这些 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 是 JIT(即时编译)的。如果修改 .csproj直接在记事本或其他一些文本编辑器中文件，你会看到 <MvcBuildViews>设置为 false - 只需将其设置为 true但要知道这会增加您的编译时间。