为什么C#没有像VB这样的Handles子句？

Question

在VB中,我们有Handles子句,它允许将Handler添加到控件的事件中,而不将其放入xaml文件中(直接放入VB文件中).

XAML:

<Button x:Name="myButton" />

VB:

Private Sub Button_Click() Handles myButton.Click

End Sub

可以使用该做的好处之一是使用Visual Studio的下拉列表中自动添加事件,而不需要去XAML文件,并改变它的可能性.阅读这个问题(和答案),以便更好地理解我在说什么:

Visual Studio 2010显示来自代码的可用事件

这个问题的答案并没有具体说明为什么C#没有在Visual Studio中这个功能,但很明显对我来说:因为它使用了Handles子句对代码隐藏添加事件C#不具备此功能.

我知道我们可以使用+ =并在构造函数上手动添加事件,在InitializeComponent下面(这几乎是同一件事),但是VB也有AddHandler可以在构造函数(以及其他地方)上添加事件,并且它不是自动的,对我来说不如Handles条款可靠.

我的问题是:

为什么它从未实施？这不可靠吗？非安全？有什么解决方法吗？

Answer 1

它从未实现过,因为微软没有人认为它足以证明这一努力的合理性.确切原因只能由C#团队的某个人来回答.虽然C#和VB已经努力同步它们的功能,但这并不意味着它们将追溯性地在C#中引入所有VB特定的功能,反之亦然.(注意该Handles子句一直存在于VB.NET中)

但是,人们可以根据VB的历史推测它为什么可能被引入的语言.也就是说,VB之前的VB事件总是如此工作,因此VB开发人员可能会习惯它.

在传统的VB中,事件按名称连接到对象.如果您有一个Form并且您定义了一个名为的子例程Form_Load,它将作为您的表单Load事件运行.这种传统延续到ASP中,并且仍然作为AutoEventWireup配置选项而存在.VB开发人员习惯了这种语言,知道为哪些事件运行哪种方法而不必向编译器"解释".

在.NET语言中,事件只是一种特殊类型的属性,具有特殊类型(委托类型),必须像任何其他属性一样分配.但是,为了让VB开发人员能够轻松地过渡到VB.NET,理想情况下,无需了解事件,代理和处理程序(至少不会立即),就可以轻松地为他们提供这样做.该Handles关键字实现这一点-你只是钉在Handles Load到你的Form_Load子,它变成一个事件处理程序.

另一方面,C#没有需要维护的遗留行为.C#的目标受众包括来自多种语言的人,其中大多数没有内置的事件概念,当然也没有VB的自动连线行为.所以没有必要在语言中引入这种行为,相反,新的C#开发人员只会从一开始就学习做事的"正确方法".

随着WPF和MVVM视图/模型分离的引入以及对最小代码隐藏的推动,handles关键字变得更具吸引力,但它似乎仍然违背了C#处理事件的一般原则.我怀疑要让C#团队相信它值得实施需要一个非常强大的论据.