c# - Excel VSTO 和 Ninject.Extensions.Factory 中的依赖注入(inject)

Question

我正在尝试为 Excel VSTO 项目配置 DI。

为给定工作表生成的代码隐藏为我提供了一个名为 Startup 的事件，它负责为 Startup、Change、BeforeDoubleClick 等事件设置事件处理程序。

我认为避免代码隐藏文件中的代码通常是一个好习惯。
我所做的是创建负责操作工作表和调用外部代码(如 Web 服务、数据库和域逻辑)的外部类。

我可以成功创建一个由代码隐藏文件使用的工厂并实例化工作表逻辑类。

例如:

//...inside Sheet1.cs

private IExpenseWorksheetFactory _factory;

void ExpensesBeforeRightClick(Excel.Range target, ref bool cancel)
{
    Application.EnableEvents = false;

    var popup = _factory.CreateContextMenu();
    popup.ShowContextMenu(target, ref cancel);

    Application.EnableEvents = true;
}
// ... rest of Sheet1.cs

上面的代码位于 Visual Studio 生成的代码隐藏文件中，而且它是最小的。显示弹出窗口的责任委托(delegate)给一个不同的对象。工厂对象负责与 Ninject 对话并为我获取对象。当我传递这样的接口(interface)时，此代理是使用 Ninject.Extensions.Factory 项目自动生成的:

/// <summary>
/// Abstract Factory for creating Worksheet logic objects. Meant to be used with Ninject Factory extension.
/// </summary>
public interface IExpenseWorksheetFactory
{
    ExpenseWorksheet CreateWorksheet();
    ExpenseWorksheet.ContextMenus CreateContextMenu();
    ExpenseWorksheet.Events CreateEventHandlers();
}

在应用程序启动时，我定义了绑定(bind)和工厂本身的绑定(bind):

//instantiate the kernel in app's Composition Root
_kernel = new StandardKernel();

//worksheet related stuff - seems to be ok to be singleton
_kernel.Bind<ExpenseWorksheet>().ToSelf().InSingletonScope();
_kernel.Bind<ExpenseWorksheet.Events>().ToSelf().InSingletonScope();
_kernel.Bind<ExpenseWorksheet.ContextMenus>().ToSelf().InSingletonScope();

//"automagic" factories
_kernel.Bind<IExpenseWorksheetFactory>().ToFactory();

问题是:

如何在 VSTO 工作表的生成代码中注入(inject)这个工厂？我不喜欢调用 _kernel.Get<IExpenseWorksheetFactory> 的想法在工作表的 Startup 方法中。是否可以查找 Sheet1 的所有可用实例并强制注入(inject)工厂？

Answer 1

简短回答:否。

您正在寻找诸如构造函数注入(inject)之类的东西，它看起来更优雅。但事实上，这在这里是不可能的，因为您无权访问 VSTO 插件中的 c'tor。

但是无论如何，调用_kernel.Get<IExpenseWorksheetFactory>有什么不好呢？ ？毕竟，显式调用 DI 容器来解决依赖关系是其正常用例之一，而代码隐藏文件正是为此而创建的:连接起来。

您是对的，代码隐藏不应包含任何业务逻辑，但另一方面，它绝对应该包含连接起来所需的所有代码。这是它存在的主要原因。或者，换句话说:

I think is generally a good practice do avoid code in code-behind files.

并非在所有情况下都是正确的(但仅适用于绝大多数情况)，您不应该在这里做得太过分。如果这样做，您会发现自己在与系统作斗争 - 请记住，系统总是会赢 ;-)...