C# DI的正确项目/构建设置

希望是直截了当的。我在看一个C#产品，由于Xamarin，它可能有桌面（WPF）、web和任意数量的移动构建输出

有几个组成部分：

• 我有一个“CoreApi”项目，它有接口和共享模型，可以调用这些接口和模型来编写任何应用程序前端（并实现为编写后端）
• 我还将所有“应用程序逻辑”放在另一个程序集中——目前的样式与MVVM模式中的模型相似，但以应用程序为中心
• applogic中包含一个特定于平台的接口实现，它涉及动态生成用于播放的音频缓冲区。单独的项目/组装

我用的是Ninject，效果很好。但随着解决方案逐渐扩展到包括其他项目类型（web、移动客户端），我可以预见一些“气味”：

目前，客户端项目引用了特定于平台（DirectX）的音频引擎和后端的本地/测试实现。它仍然使用Ninject，并且不直接引用实现类，但是让它们像这样可访问和直接引用是错误的

在构建解决方案时，我几乎希望有不同的“包”：

• 包1：桌面客户端+DirectX引擎+后端X
• 包2：带有后端Y的Web部署包
• 软件包3:Android版本与后端X+Android音频引擎

---

我走对了吗？我真的想求助于生成后步骤，将内容复制到目标文件夹吗？

我会考虑使用MSBuild功能执行必要的复制。我采用了使用dependency.proj文件的方法，您可以根据选择设置的任何配置选项对其进行配置以执行适当的复制操作，例如，您可以根据配置和CPU类型将特定文件复制到输出文件夹中。我不主张使用老式的后期构建步骤，因为这些步骤不可靠，而且很难调试。在我看来，MSBuild是前进的方向。

在打包它时是否会处理此问题？例如，Xamarin的包将做什么？我不知道-我不想依赖它，因为我不仅仅是在创建Xamarin包。实际上，这个问题是关于更大的问题：我在使用DI，但是我应该如何在不使用Add引用的情况下将不同的实现模块组合在一起，以整洁/干净的方式？我怀疑这是你可以使用MEF的东西。我不确定我是否会提倡这样做，但值得一看。MEF是一个DI框架，但我指出我已经在使用Ninject:）