Question

在XAML文件后面的代码中，如果我的DataContext始终是一个众所周知的类，我通常会重新声明DataContext，如下所示：

public new Cow DataContext
{
    get { return base.DataContext as Cow; }
    set { base.DataContext = value; }
}

这样我就可以在我的文件范围内将DataContext作为一个Cow处理，我很安全（至少我是这么认为）使用 base.DataContext来处理它的所有逻辑。

有些人有很多经验，已经告诉我这不是一个好的模式。

我想知道可能出现的问题以及为什么不使用它。我已经考虑了很多，想不到一个

谢谢

Answer 1

在思考了一段时间之后，我找不到任何严重的问题，除非是我要解释的这个角落案例。

假设您的Xaml属于一个名为MyUserControl的类，并且它继承自UserControl。

我们假设你有：

UserControl ctrl = new MyUserControl();
ctrl.DataContext = new Dog();

这显然是合法的，并且您不受MyUserControl类型安全性的保护，因为引用变量的类型是UserControl，其DataContext属性仍然是对象类型。但是，让我们想象一下，在MyUserControl的上下文中尝试以下内容：

Cow c = this.DataContext;

c将为null。这就是你的意图。但是，它可能会使您在调试场景中的生活变得更加困难，因为您会认为您的DataContext为null，而它根本不是您所期望的那样。当你的datacontext似乎为null时，可能更难理解为什么你的数据绑定都很有趣。

我的方法不是隐藏DataContext属性，而是通过新属性重新公开它：

public Cow Model
{
    get
    {
        return this.DataContext as Cow;
    }
    set
    {
        this.DataContext = value;
    }
}

在我上面设置的场景中，当Model属性返回null时，DataContext将返回对Dog实例的引用，更恰当地反映了实际发生的事情。或者，您可以通过返回以下内容来实现DataContext属性的getter：

return (Cow)this.DataContext;

至少你会收到一个异常，告诉你DataContext确实有什么东西，但不是你想要的东西。然而，它确实看起来很俗气。

无论如何，这确实不是一个严重的问题，只是在我设定的情景下可能带来的不便。

Answer 2

好吧，我没有发现任何问题，这只会对IntelliSense有帮助......它不会将DataContext依赖属性改为Cow ...所以就绑定或样式等WPF功能而言，没有类型安全性