依赖注入的技术已经很成熟，本文主要是说明一下Revit中的适用版本与介绍相关的开源项目。
版本问题
版本
目前的依赖注入包无法支持Revit 2020 以下的版本，原因是因为包中的依赖项与Revit本身的依赖项不一致导致的，所以说如果使用Revit + DI 进行开发需要再2020以上 。 如果有其他方式可以通过评论介绍一下，一起交流。
原因
因为我常用版本在2019 ， 在我使用DI时引用了Microsoft.Extensions.Hosting这个包开发，但是每次开发都是报错，开始时我认为是我的开发引用与这个包内部依赖项冲突，所以单独做了项目进行引用，但是依旧报错，但是更换版本在Revit 2021 可以正常使用，所以怀疑Revit本身加载的依赖项与这个包发生冲突。
于是搜索资料，发现相关的资料很少，在网络上使用Revit + DI 的资料也相对较少，这里找到一个资料中间讲了这个事情，与我的预估基本一致，jimmy在下面回复也是需要通过复杂的方式(IPC)桥接。
How to force a host application to load a .Net addin’s version of transitive dependencies
Revit +DI
依赖注入的讲解与视频网络上面很多，这里提供两个网址一个是开源项目一个是原理讲解，需要的可以看一下
依赖注入 - 看这篇就够了
RevitLookup
–
RevitLookUp在2020之后与另一位开源作者Nice3point合作，将框架更改为DI，所以需要学习的可以直接下载这个文件下来自己学习使用。
说一下我现在应用方向，因为目前2020以上的版本开发较少，所以可能会理解错误，但是暂时记录现在后续再逐渐扩充。
假设每个方法都是X_Command ， 如果我们自己的插件功能数量超过20个，可能我们会自己集成一套自己的Tool方便开发，基于此，如果直接测试插件功能可能会面临频繁的启动Revit或者我们单独创建一个项目将代码copy过去测试，完成后再copy回去，这种方式的效率会比较慢。
如果我们自己创建一个接口，所有的command主要代码继承这个接口，我们只需要做一个测试项目，使用依赖注入加载这个方法从而测试会更加方便。
Core_Di_Test作为Revit所有功能的项目，里面仅有操作部分的代码不涉及Application 与 Command,
让每一个想要编写的功能均继承基础的接口
namespace Core_Di_Test
{
public class Class1:IWorkInterface
{
public void Start()
{
TaskDialog.Show("A", "M");
}
}
public interface IWorkInterface
{
void Start();
}
}
测试文件 ， UI 文件或是其他应用场景
public class Class1:IExternalCommand
{
public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
{
// TaskDialog.Show("A", "n");
RevitApi.UiApplication = Context.UiApplication;
//var host = Host.CreateDefaultBuilder();
var host = Host.CreateDefaultBuilder().ConfigureServices(build =>
{
//build.AddSingleton<IExtensionCommand, ReadFamilyParameter>();
build.AddTransient<IWorkInterface, Class1>();
}).Build();
host.Services.GetService<IExtensionCommand>().Start();
//TT.Test(commandData.Application.ActiveUIDocument.Document);
return Result.Succeeded;
}
}
这样就可以将功能的主要代码与测试，UI，部署分离，从而减少代码之间的耦合度，增加我们的开发效率。
