我有一个多部分的问题：
（1）Silverlight没有公开DataContextChanged事件是否有充分的理由？如果微软的某个人刚刚在FrameworkElement类中将internal更改为public（就像WPF那样），那么似乎可以避免很多麻烦。
（2）通过在一个配置或另一个配置中使用DependencyProperties，我发现了one或two个不同的方法来攻击DataContextChanged事件。但我不能让他们可靠地工作。到目前为止，我的测试似乎表明他们触发了被攻击的DataContextChanged事件，这对我连接它的第一个类来说很好，但是不要为任何其他类触发。还有其他人遇到过这个问题吗？或者更好的是，他们是否一直在努力？
（3）我之所以想要知道我的DataContext何时发生变化，是因为有些UI操作在XAML中很难实现，但在代码隐藏方面是微不足道的。对于其中许多事情，我需要处理由我的ViewModel引发的事件;因此我需要知道我的ViewModel何时发生了变化，所以我可以连接事件处理程序。这是对世界的准确看法吗？或者事实是我想要在代码中处理这类事情，这是一个非常好的迹象，表明我的想法在某种程度上已经脱离了轨道？我不是MVVM纯粹主义者：我只是想快速从这里获得良好的代码，我并不特别在意我是如何到达那里的。十多年来，代码隐藏已经为我提供了相当好的服务，我完全放弃它。但是，我的实用主义在这一点上让自己变得更难吗？
答案 0 :(得分：2)
“但我的实用主义让它变得更难 在这一点上我自己？“
我不会称之为实用主义。我称之为害怕改变;住在你的舒适区。如果你放弃旧的思维方式并接受新的思维方式，那么生活实际上要容易得多（而且我确切地知道你的意思 - 我和你在同一条船上使用代码隐藏）。
现在，关闭我的肥皂盒并回答更实际的答案：
如果要检测模型中的更改，请勾选允许您检测模型中的更改的事件。 DataContext实际上并不是模型......所有模型对象都将具有INotifyPropertyChanged的实现。您应该为给定模型挂钩，或者为ObservableCollection挂钩。
Silverlight / WPF使得所有这些东西变得更容易，因为数据绑定实际上正常工作。
不要与框架作斗争。不要把旧的ASP.Net做法带到这个游戏......这对你没有帮助。你会以这种方式失去框架功能的最佳部分。
干杯。