c# - DI对象图构建——分离逻辑和构造图

Question

很抱歉，如果这是一个非常基本的问题，但它真的让我很困扰。我真的很喜欢 DI 的想法，它确实对我的测试有帮助，但我认为我遇到了一些困难。所以我有两种类型:

 Table
 TableManager

现在表对象上有一个构造函数，如下所示:

Table(ITableCommandRunner tableRunner,
      IQueryProvider queryProvider,
      IDataReader reader,
      string Name)

现在表对象几乎只使用这些对象，所以遵循你询问你需要什么的规则，我将它们传入。现在我的 TableManager 对象用于打开和关闭等表。它唯一需要的是一个 ITableCommandRunner，所以我在构造函数中传递了它。

 TableManager(ITableCommandRunner tablrunner)

好的，但在 TableManager.OpenTable 命令中，我需要在 ITableCommandRunner 上调用打开表命令，然后构造一个新的 Table 对象以传回。

    public ITable OpenTable(string tableName) 
    {
        // Call open table command on tablerunner.
        // I need a IQueryProvider and IDataReader to pass to the table.
        return new Table<TEntity>(this.tablerunner, provider,reader, tableName);
    }

但现在在我的打开表命令中，我必须创建一个 IDataReader 和 IQueryProvider。如果我将它们传递给 TableManager 的构造函数，这并不违反“获取对象只是为了将其传递给内部类型而不是真正使用它们”。

我不太确定我该怎么做。谁能帮我解决这个问题？

我只是不确定如何分离对象构造和逻辑。

Answer 1

一个选项是配置一个TableFactory，它确实知道查询提供者和阅读者，并且只需要知道表名。然后您可以将工厂传递给 TableManager。另一方面，TableManager 听起来好像它可能需要成为工厂本身 - 在这种情况下，它很简单确实需要提供者和阅读者，即使它可能不是鉴于它只是传递它们，所以一开始就很明显。

我同意它有点困惑 - 基本上如果“树的深处”(动态创建)的东西需要一条信息，那么创建它的任何东西都需要该信息 - 并且创建者需要它的任何东西，等等。它如果您不小心(有时即使您很小心)，肯定会变得一团糟。

根据您的 DI 框架，您可以在容器中配置一个类似工厂的对象，然后要求它在执行时创建一个新实例。这意味着您的代码当然会与 DI 框架耦合——这是一个摇摆和迂回的例子。基本上信息必须位于某处，并且您总是需要一些“引用链”以便在需要时访问它。

很抱歉没有对此有更乐观的看法，但即使这些想法对你没有太大帮助，至少你知道你并不孤单:)