我有一个由多个部分组成的问题：
(1) Silverlight 不公开 DataContextChanged 事件是否有充分的理由？如果微软的某个人做出改变，似乎可以避免很多麻烦internal to public在 FrameworkElement 类中（就像 WPF 那样）。
（2）我发现one http://www.codeproject.com/Articles/38559/Silverlight-DataContext-Changed-Event.aspx or two http://www.pochet.net/blog/2010/06/16/silverlight-datacontext-changed-event-and-trigger/通过在一种或另一种配置中使用 DependencyProperties 来侵入 DataContextChanged 事件的不同方法。但我无法让它们可靠地工作。到目前为止，我的测试似乎表明，它们对于我将它们连接到的第一个类触发了被黑的 DataContextChanged 事件，但不会对任何其他类触发。还有其他人遇到过这个问题吗？或者更好的是，他们有办法解决这个问题吗？
(3) 我之所以一直想知道 DataContext 何时发生更改，是因为有一些 UI 操作在 XAML 中很难正确执行，但在代码隐藏中却很简单；对于其中许多事情，我需要处理由 ViewModel 引发的事件；因此我需要知道我的 ViewModel 何时发生更改，以便我可以连接事件处理程序。这是正确的世界观吗？或者我想在代码隐藏中处理这类事情这一事实是否很好地表明我的想法在某种程度上已经偏离了轨道？我不是 MVVM 纯粹主义者：我只是想快速从这里得到好的代码，而且我并不特别关心如何到达那里。十多年来，代码隐藏一直为我提供了相当好的帮助，我不愿意完全放弃它。但此时此刻，我的实用主义是否让我自己变得更加困难？
“但是我的实用主义是否让事情变得更加困难
这个时候就针对我自己了？”
我不会称之为实用主义。我称之为对改变的恐惧；留在你的舒适区。如果你放弃旧的思维方式并拥抱新的思维方式，生活实际上会容易得多（我确切地知道你的意思 - 我和你在代码隐藏方面处于同一条船上）。
现在，离开我的肥皂盒，得到一个更实际的答案：
当您想要检测模型中的更改时，请挂钩允许您检测模型中的更改的事件你的模型。 DataContext 并不是真正的模型...所有模型对象都将具有 INotifyPropertyChanged 的实现。您应该要么挂钩给定模型，要么挂钩类似的 ObservableCollection。
Silverlight/WPF 使所有此类事情变得更容易，因为数据绑定实际上有效.
不要对抗框架。不要将旧的 ASP.Net 实践带到这个游戏中...它不会对您有帮助。这样您将失去框架功能的最佳部分。
Cheers.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
