.net - MEF 和 N 层域驱动设计架构的正确解耦

Question

我一直在阅读 Microsoft 的 NLayered Domain Driven Design Architecture 指南，我想将 MEF 实现为我的 DI 容器。

我想通过创建 3 个项目来测试 MEF:只有接口(interface)的 ContractProject。 ImplementationProject 具有使用 Export[typeof(Interface)] 注释实现此接口(interface)的类。和一个控制台应用程序来测试这一点。

根据依赖注入(inject)原则，高层不应引用低层，反之亦然。它们都应该引用一个抽象层(接口(interface))。

我试着应用这个。控制台应用程序引用 ContractsProject， implementationProject 引用 ContractsProject。但是如果程序集中没有 ImplentationProject dll，MEF 找不到 EXPORT 类。我看过一个教程，他们手动将 dll 添加到 MainApp 的 bin 文件夹中。好消息是您不能通过动态避免“添加引用”来直接访问实现方法，但我认为这不是正确的做法，因为每次更改时我都必须手动添加 dll。使用 NLayered Domain Driven Design 架构应用程序，我需要很多 dll。

这是否意味着 MEF 不是依赖注入(inject)所需的正确工具？ (本书使用Unity)

这是代码:

namespace Contracts
{
    public interface ISampleContract
    {
        string DoSomething();
    }
}

namespace Implementation
{
    [Export(typeof(ISampleContract))]
    public class Sample : ISampleContract
    {
        public string DoSomething()
        {
            return "I did something ";
        }
    }
}

程序:

namespace Console
{
    class Program
    {
        [Import]
        public ISampleContract sample { get; set; }

        static void Main(string[] args)
        {
            Program p = new Program();
            p.Run();
        }

        public void Run()
        {
            var catalog = new AggregateCatalog(
            new AssemblyCatalog(Assembly.GetExecutingAssembly()),
            new DirectoryCatalog("."));
            var container = new CompositionContainer(catalog);

            container.ComposeParts(this);
            Console.WriteLine(sample.DoSomething());
            Console.ReadKey();
        }
    }
}

如果我没有在主程序中引用实现 dll，那么 ComposeParts() 事情会失败，因为它找不到与约束匹配的导出......有没有办法在不引用 dll 的情况下解决这个问题，或者我应该完全选择另一个 DI 工具？比如 Unity？

编辑
如果我在实现项目上配置构建后事件以将其 dll 复制到我的控制台 bin，它会起作用。我不确定这是否是一个好的解决方案？

copy /Y "$(TargetFileName)" "$(SolutionDir)Console\bin\Debug\$(ProjectName).dll" 

Answer 1

您应该确保 Visual Studio 实际上正在构建 Implementation.dll。通常如果你只构建 Console.dll 会发生什么 Console.dll 并且它的依赖项是构建的。任何 DI 框架都会有这个问题。

解决此问题的一种方法是转到解决方案 -> 属性 -> 项目依赖项并在那里标记构建依赖项。 (请注意，dll 将位于它们自己的项目 bin 目录中，您可以在构建后步骤中将它们全部部署到插件目录中)

在稍后阶段，您可能会或可能不会设置一些更高级的工具来独立构建和部署您的 implementation.dll(我只会在合理的大型项目或具有特定插件要求的项目中这样做)

编辑 :unity(和其他一些)的缺点是它经常演变为创建一个巨大的映射文件(迫使你同时拥有构建和代码依赖)。