在生产代码中使用PrivateObject而不是Reflection

Question

“反射”是指使用System.Reflection命名空间。

MSDN谈到PrivateObject类：“允许测试代码......”。我喜欢一个比System.Reflection更多的PrivateObject语法，所以我想知道是否有一个真正的理由不在生产代码中使用它，只保留它用于单元测试？

Answer 1

我可以让您在生产环境中不使用PrivateObject的一个原因是需要将测试程序集（Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll）部署到生产服务器。那不是他们应该去的地方。但如果它不会影响您工作地点的任何政策，则由您决定是否使用它。

顺便说一句，PrivateObject内部使用Reflection，所以无论如何你都会使用它。

我发现这个解决方案使用动态对象来调用私有成员（http://blogs.msdn.com/b/davidebb/archive/2010/01/18/use-c-4-0-dynamic-to-drastically-simplify-your-private-reflection-code.aspx），因为你不喜欢Reflection的语法。也许你应该试试。

Answer 2

“真正的原因”是，不属于您的项目的某个类的私人成员不打算由您的代码使用或修改。

来自Wikipedia：

  

在编程语言中，封装用于指代两个相关但不同的概念之一，有时用于组合 ^{[1] [2]} 物：

     

  
• 限制访问某些object组件的语言机制。 ^{[3] [4]}
  
• 一种语言构造，有助于将数据与对该数据进行操作的methods（或其他函数）捆绑在一起。 ^{[5] [6]}
  

故事的寓意是修改不属于您的类或组件的私有数据成员类似于 undefined behavior 。这意味着，如果您修改这些私有成员，可能会发生任何事情 - 它可能正常工作，可能会使您的应用程序崩溃，或者它可能会格式化您的硬盘驱动器。

您应该考虑寻找解决方法，从组件供应商处请求特定功能或使用其他组件，而不是使用PrivateObject或反射来执行您不应该执行的操作。

Answer 3

您无法使用PrivateObject在某个类型上实际反映。换句话说：你不能用它来获得一个类型的成员 如果您事先知道成员的姓名，则只能使用它。

那就是说，如果这些限制在你的场景中无关紧要，我看不出你不应该被允许使用它的原因。 该类为public，有详细记录，不予弃用。