(Ab)可以使用CoClassAttribute为接口提供默认实现吗？

Question

我最近发现，C#中的“新建”接口可以通过使用CoClassAttribute来修饰接口来指定默认实现。

[ComImport, Guid("579A4F68-4E51-479A-A7AA-A4DDC4031F3F"), CoClass(typeof(FooImpl))]
public interface IFoo
{
    void Bar();
}

public class FooImpl : IFoo
{
    public void Bar() { }
}

...

// Constructs a FooImpl
IFoo foo = new IFoo();

我知道这个特性主要是为了支持COM-interop，但我想知道这是否是将接口与一般类库中的默认实现相关联的合理方法。

我有两个问题：

1. 这么做有什么问题吗？我不是COM-interop方面的专家，我不知道这是否会对POCOs产生任何负面影响。我还没有运行任何主要的测试，但是我的例子中的IL似乎还好( FooImpl上的一个普通的FooImpl指令，而不是对Type.GetTypeFromCLSID和Activator.CreateInstance的调用)。
2. 即使这样做能顺利进行，还有其他原因(比如从API设计的角度)来避免这种情况吗？

Answer 1

不应该这样做的关键原因是，您正在一个不需要COM生命周期的对象的实例上启动COM生命周期管理。现在，.NET将不得不进行一些COM互操作，包括安全堆栈遍历、公寓线程检查和addref/release内容。

相反，我会考虑考虑依赖注入(控制模式的反转)和公共服务定位器模式。我将侧重于理解构造函数注入，因为它是依赖关系管理的首选模式。

这是我在图书馆里做的事。假设我想编写一个日志记录服务(人为的例子)。我将有两个核心组成部分：

MyStuff.Logging.Contracts --这里是我声明ILogger接口MyStuff.Logging的地方--这里我将编写不同的日志实现，比如FileLogger、DatabaseLogger等等。

然后，在我的应用程序中，我将使用Ninject或Unity (DI容器)将ILogger与默认实现相关联。

Answer 2

使用智能注释：

    /// <summary>
    /// Explain here all about interface
    /// </summary>

而不是侵入属性，因为它可能会在其他人使用类的半反射实现中适得其反。属性由使用反射的工具使用，智能用于文档。

当然，一些遗留工具在读取/注释时会遇到问题，但它们也无法读取您的属性。