使用带反射的动态答案

【问题标题】：using dynamic with reflection使用带反射的动态
【发布时间】：2013-09-19 22:27:04
【问题描述】：

我听说使用反射创建实例的最佳做法是使用动态类型变量。这意味着当我们使用Activator.CreateInstance() 方法（返回对象）时，我们将其分配给动态类型而不是对象类型：

dynamic dog = Activator.CreateInstance("Zoo.Dog");
dog.Bark();

代替：

object dog = Activator.CreateInstance("Zoo.Dog");
Dog realDog = (Dog)dog;
realDog.Bark();

除了没有强制转换之外，还有什么好的理由使用动态？

【问题讨论】：

请添加语言标签。
dynamic 旨在实现与脚本语言的互操作性，或与其他类型的不具有通用静态类型的对象一起使用。（ASP.NET MVC ViewBag、ExpandoObject 等等。）此外，“缺少强制转换”并不能真正准确地描述它是如何工作的——动态方法调用/表达式的处理方式与静态方法调用/表达式的处理方式完全不同。
我知道什么是动态。我的问题是为什么我上面显示的示例在使用反射创建实例时被认为是最佳实践
是它真的是最佳实践吗？我的意思是，如果您应该只知道要在运行时实例化的类（因为您无法在编译时知道正确的类型），那么它在某种程度上是唯一优雅的选择。如果我在设计时知道类型，我总是更喜欢静态类型 - 没有一个缺点......

【解决方案1】：

如果您有权访问创建实例的类型，则无需使用dynamic 类型。如果您无法（以静态方式）访问该类型，例如在动态加载程序集时，您可能需要使用 dynamic 类型。如果您使用动态类型而不是已知类型，则您调用的每个类型都将在后台使用反射。此外，您不会使用dynamic 类型进行智能感知。

您可以使用Activator 类中的通用方法CreateInstance<T> 来创建您的实例。

Dog dog = Activator.CreateInstance<Dog>();
dog.Bark();

dynamic 关键字使与动态语言（例如 IronPython、IronRuby）(Dynamic Language Runtime DLR) 或 COM 互操作 API 的交互变得更容易，但不建议（也不需要）将其与已知类型一起使用。

【讨论】：