更好地编写带有COM限制的.NET库，还是将.NET库与Interop分开？

我碰到了一篇有趣的文章：我如何爱上 CodeProject上的COM互操作性，这让我开始思考...

作者认为，他们不希望在.NET库中有任何COM-ity，因为它剥夺了.NET库的美感。相反，他们宁愿编写一个单独的Interop库，以将其.NET库公开给COM。该Interop库将处理以下事实：COM不支持带参数，重载方法，泛型，继承，静态方法等的构造方法。

虽然我认为这很新颖，但它不只是使项目变得复杂吗？

• 现在，您需要对.NET库和一个Interop库进行单元测试。
• 现在，您需要花时间弄清楚如何解决漂亮的.NET库并将其公开给COM。
• 您需要有效地将班级人数增加一倍或两倍。

我当然可以理解您是否需要您的库来支持COM和非COM。但是，如果仅打算使用COM，这种设计是否会带来我看不到的好处？您仅获得C＃语言的好处吗？

还是通过提供包装器使库的版本控制变得容易？是否通过不需要使用COM来使您的单元测试运行更快？

但是，如果仅打算使用COM，这种设计是否会带来我看不到的好处？

你的问题的这个片段是在你的设计决策的最重要的部分在这里，答案是（一如既往），它依赖。

如果仅打算通过COM Interop使用该库，则应牢记这一点设计整个系统。没有理由使行数增加三倍。系统中的LoC越多，缺陷就会越多。因此，您应该将系统设计为仅使用COM兼容功能。

但是，我想不出将.Net库限制用于COM的充分理由。您为什么不希望能够在其他.Net代码中使用该程序集？这样限制自己毫无意义。

我对此有一些经验，因此我将分享我的处理方式。它当然不是理想的。我做了一些折衷。我只对与较新的.Net习惯用法不兼容的COM类（实际上是接口）使用外观，否则，我直接将.Net接口公开给COM。基本上，这意味着我会将外观用于任何使用泛型的接口。泛型是我遇到的唯一不兼容的东西。不幸的是，这意味着返回的任何事物的外观IEnumerable<T>，这是很常见的。

但是，这并不像看起来那样糟糕，因为您的Facade类继承自.Net类并实现了特定的Interop接口。这样的东西。

namespace Company.Product.Feature
{
    public class MyClass : INetInterface 
    {
        // lots of code
    }
}

namespace Company.Product.Interop
{
    public class MyClass : Feature.MyClass, IComInterface
    {
        // over ride only the  incompatible properties/methods
    }
}

这样可以将重复的代码保持在最低限度，并保护您的COM接口免受“意外”更改。随着核心类/接口的更改，适配器类必须使用更多方法（或破坏接口并增加主版本号）。另一方面，并​​非所有的Interop代码都存储在Interop名称空间中，这可能导致文件组织混乱。就像我说的，这是一个权衡。

对于完整的示例，您可以浏览我的仓库的SourceControl和Interop文件夹。ISourceControlProvider并GitProvider会引起特别的兴趣。

它带走了他们的.NET库的美丽

那位作者需要醒来一巴掌。对于任何专业项目，目标都是制作人们想要使用的工作软件。在那之后，关于美的任何一种误导的理想都会随之而来。如果这只是他们的唯一理由，那么作者将失去所有信誉。

能够将您的类标记为com-visible并能够通过COM与.NET代码进行对话非常有用。放弃对美容生产率的巨大好处是疯狂的。

但是，使事情与COM配合使用确实需要权衡取舍，其中一个需要no-arg构造函数，而您提到的其他一些东西也需要。如果这些功能还是您不使用，或者不使用它们不会对您造成伤害，那么对于COM和non com使用相同的类可以节省很多工作。

另一方面，如果您的COM客户端期望一个截然不同的接口，在.NET类中具有令人讨厌的依赖关系或其他限制，或者您希望显着更改.NET类并需要向后维护COM，兼容性，然后一定要创建一个Interop类来弥合这种差距。

但是不要考虑“美容”。能够通过.NET公开COM意味着可以节省您的工作。不要为自己创造更多的工作。

好吧，公平地说，该文章的原始作者在他的文章中的任何地方都没有使用“ beauty”一词，这就是您，这可能给那些没有时间阅读本书的人带来偏见。他们自己。

据我所知，.NET库已经存在并且在编写时就没有考虑到COM，这可能是因为在创建该库时，并不需要支持COM。

后来，引入了支持COM的其他要求。面对这种情况，您有两种选择：

• 重新设计原始库，使其与COM互操作兼容（可能会损坏东西）

• 保留原始工作库的大部分内容，而是使用“包装器”（或“适配器”）的功能创建一个单独的程序集

创建包装器或适配器是一种众所周知的设计模式（在这种情况下，更多的是一种建筑模式），其优缺点也是众所周知的。一种说法是更好的“关注分离”，与美无关。

对于您的担忧

现在，您需要对.NET库和一个Interop库进行单元测试。

通过重新设计将COM接口引入现有.NET库时，您必须测试该接口。当然，引入手动编写的适配器可能需要一些其他测试来证明接口正在运行，但是不需要复制lib核心业务功能的所有单元测试。别忘了它只是lib的另一个接口。

现在，您需要花时间弄清楚如何解决漂亮的.NET库并将其公开给COM。

当您必须重新设计原始库时，您也必须弄清楚这一点，我想这将需要更多工作。

您需要有效地将班级人数增加一倍或两倍。

仅适用于通过公共COM接口公开的类，这些类应该是原始库的一小部分。

据说，对于您提到的另一种情况，当您已经知道从一开始就必须支持COM作为一等公民时，我认为您是正确的：应该避免添加单独的适配器库并设计适配器的麻烦。直接支持COM的.NET lib。