“新起来”接口

Question

几天前，我看到CoClassAttribute以一种我以前从未想过的方式使用。

[ComImport, CoClass(typeof(Foo)), Guid("787C1303-AE31-47a2-8E89-07C7257B1C43")]
interface IFoo {
    void Bar();
}

class Foo : IFoo {
    public void Bar() {
        Console.WriteLine("Oh retado!");
    }
}

被用作：

class CoClassDemo {
    public static void Show() {
        var a = new IFoo();
        a.Bar();
    }
}

这不应该让我感到惊讶，因为COM Interop从.NET框架的早期就做到了这一点。在.NET Reflector中挖掘COM互操作代码时，我根本没有注意到这一点。

method public hidebysig static void Show() cil managed
{
    .maxstack 1
    .locals init (
        [0] class ConsoleApplication1.IFoo a)
    L_0000: nop 
    L_0001: newobj instance void ConsoleApplication1.Foo::.ctor()
    L_0006: stloc.0 
    L_0007: ldloc.0 
    L_0008: callvirt instance void ConsoleApplication1.IFoo::Bar()
    L_000d: nop 
    L_000e: ret 
}

所发生的情况是，在COM Interop的上下文中，我立即设想将其用作穷人的编译时依赖项注入。

所要做的就是去掉接口名称上的常规"I“前缀(就像COM Interop一样)。

然后，将CoClass属性更改为将一个实现替换为另一个实现、模拟等等。

我看到的两个缺点是必须重新编译(这在很大程度上限制了测试场景的开发时间)，以及当接口和实现部署到不同的程序集时，围绕循环依赖关系的最终问题。

有人玩过这种技术吗？还有其他缺点吗？其他用途？

Answer 1

我知道这个周末至少有两篇博文-- 我的和艾因德氏。

对于大多数代码来说，这仅仅是一种好奇。我认为将其用于依赖注入是一种滥用，因为所建立的IoC/DI框架可以更好、更简单地完成这项工作。

特别是，这种方法依赖于§17.5的逸出舱口，它是Microsoft对规范的扩展.你想让你的代码在Mono上运行吗？我还没有试过它，但是在gmcs / dmcs下编译它没有具体的原因。

Jon有一个在具体代码中使用它的更好的例子 --用来故意嘲弄COM，但这是用来玩.NET 4.0 / dynamic的。同样，这将不适用于大多数“常规”代码。

所以，不，不做，-这只是一个有趣的一边。