Effecitve C# 原则46：最小化与其它非托管代码的交互

核心提示：在开发设计.Net时，MS所做的最聪明的修改之一就是他们意识到，Effecitve C# 原则46：最小化与其它非托管代码的交互，如果没有办法整合已经存在的代码到新的.Net环境中，那没没有人会接受这个新的平台，整个第5章都推荐使用"throw it out“策略，这一原则就专注于交互，MS知道，

在开发设计.Net时，MS所做的最聪明的修改之一就是他们意识到，如果没有办法整合已经存在的代码到新的.Net环境中，那没没有人会接受这个新的平台。MS知道，如果没有办法来利用已经存在的代码，这将阻止大家接受它。与其它非托管代码的交互是可以工作了，但这是可交互唯一可以拿来说一下的有利的地方。对于所有的交互策略，当操作流程在本地代码和托管代码之间的边界上进行传送时，都要求强制提供一些 编组的信号。同时，交互策略强迫开发人员必须手动的申明所有调用参数(译注：这里是说你根本不知道参数的数据类型，很多时间你都只能以int32的方式传递所有参数，例如文件句柄，字符串指针等几乎是所有的参数，都只有一个int32也就是IntPtr类型进行处理，当然这里认为是是在32位机器上。)。最后，CLR还不能完成对托管代码和本地代码的边界上进行数据传递时的优化。忽略采用本地代码或者COM对象时得到的好处吧，没有什么比这更好的了(译注：我本人强烈反对这一原则。C++，COM在目前来说，绝对有它生存的优势，我觉得应该充分利用这些优势，而不应该忽略它们)。但事实是交互并不是总能工作的，很多时候我们还是在要已经存在的应用程序中添加新的功能，提高而且更新已经存在的工具，或者在其它的地方要完成一个新的托管应用程序与旧的应用程序交互。使用一些交互在实际应用中只会是减缓对旧系统的更替。所以，有明白不同的交互策略之间有什么开销是很重要的。这些开销要同时花在开发计划以及运行时性能中。有些，最后的选择是重写旧代码。还有一些时候，你须要选择正确的交互策略。

在我讨论这个对你有用的交互策略之前，我须要花一段来讨论放弃(just throw it out)策略。第五章，与.Net框架一起工作，向你展示了一些.Net里已经为你创建好了的类和技术，你可以直接使用或者派生。为你你想的很多，你可以确定一些类和你一些代码算法，并且全部用C#重写。剩下存在的代码可以被.Net框架里已经存在的可能功能性的派生来取代。这并不会总是在任何地方，任何时候都可以工作的，但这确实是一个经过认真考虑过的迁移策略。整个第5章都推荐使用"throw it out“策略。这一原则就专注于交互，而它确实是件痛苦的事情。