**已关闭。**此问题正在寻求有关书籍、工具、软件库等内容的建议。它不符合Stack Overflow guidelines。当前不接受答案。
我们不允许提出问题来寻求对图书、工具、软件库等的推荐。您可以编辑问题，以便用事实和引文来回答。
28天前关闭。
Improve this question的
C# 12将引入拦截器，它允许你拦截对一个方法的调用，但这有什么意义呢？为什么我不直接调用另一个方法呢？
我为什么要使用它呢--它的语法似乎对开发人员不友好？谢谢
**已关闭。**此问题正在寻求有关书籍、工具、软件库等内容的建议。它不符合Stack Overflow guidelines。当前不接受答案。
我们不允许提出问题来寻求对图书、工具、软件库等的推荐。您可以编辑问题，以便用事实和引文来回答。
28天前关闭。
Improve this question的
C# 12将引入拦截器，它允许你拦截对一个方法的调用，但这有什么意义呢？为什么我不直接调用另一个方法呢？
我为什么要使用它呢--它的语法似乎对开发人员不友好？谢谢
2条答案
按热度按时间ltqd579y1#
为什么要使用Interceptor？
问题是，你不应该直接使用拦截器，相反，它们应该由一个源代码生成器来使用，这就解释了如何处理它们以及它们的akward语法。它们并不是为了 * 开发人员友好 *。
"那他们有什么用"
一个很好的方式来使用拦截器将是嘲弄例如。
我看到了Interceptor的巨大潜力，它可以使已经很简单的任务变得更加容易。之所以最初实现它们，是因为它们是Microsoft在.Net中实现完全AOT支持的目标的一个重要里程碑，因为Interceptor执行的替换完全发生在编译时。这意味着，没有运行时开销，也不需要任何运行时交互。我相信我们会看到.net团队使用这个特性来启用反射所独有的特性，因此不能在AOT中使用。在AOT中编译的应用程序。
希望能帮上忙。
如果您想了解更多有关拦截器的信息，请参阅以下功能规范：Interceptors
6psbrbz92#
为什么不直接调用另一个方法呢？
来呼应@dragon的回答：这里的典型用例是允许生成器在构建时 * 重写 * 您的代码，以表达相同的意图，但以AOT兼容的方式。（因为我有偏见）是“Dapper”：Dapper是一个数据访问库，它使用反射和IL-emit在运行时生成代码，执行ADO.NET参数绑定和行解析等操作。但是与AOT和trimming 100%不兼容。Dapper的一个基于生成器的实现正在进行中，它采用 * 您现有的Dapper代码 *，但是使用拦截器来替换您对
.Query<Customer>(...)之类的调用，使用 * 等效 * 实现，但是现在是AOT和trimming友好的-无需对现有代码进行任何更改。语法对开发人员来说似乎不友好？
这并不需要;并不期望任何人直接或手动发出拦截器，而是总是通过生成器。