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

Question

很抱歉,如果这是一个非常基本的问题,但它真的很适合我.我非常喜欢DI的想法,它确实帮助我进行了测试,但我认为我已经打了一个砖墙.所以我有两种类型:

 Table
 TableManager

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

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

现在表对象几乎只使用那些对象,所以遵循你要求我需要的规则我将它们传入.现在我的TableManager对象用于打开和关闭等表.它唯一需要的是ITableCommandRunner,所以我在构造函数中传递它.

 TableManager(ITableCommandRunner tablrunner)

好的,但是在TableManager.OpenTable命令中,我需要在ITableCommandRunner上调用open table commmand,然后构造一个新的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);
    }

但现在在我的open table命令中,我必须创建一个IDataReader和IQueryProvider.如果我将它们传递给TableManager的构造函数,则不会违反"将对象传递给内部类型而不是真正使用它们".

我不确定我是怎么做到的.任何人都可以帮我这个吗？

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

Answer 1

一种选择是配置一个知道TableFactory查询提供程序和读取器的数据库，并且只需要知道表名称。然后您可以将工厂传递给. 另一方面，a听起来可能需要是工厂本身 - 在这种情况下，它确实需要提供者和读取器，尽管一开始可能并不明显，因为它只是传递它们。TableManagerTableManager

我同意它变得有点混乱 - 基本上，如果“树深处”（并且动态创建）的东西需要一条信息，那么任何创建它的东西都需要该信息 - 并且任何创建该创建者的东西都需要它，等等。它肯定可以成为如果你不小心的话，就会变得一团糟（有时即使你很小心）。

根据您的 DI 框架，您也许能够在容器中配置类似工厂的对象，然后要求其在执行时创建一个新实例。这意味着您的代码当然会与 DI 框架耦合 - 这是一个摇摆和迂回的情况。基本上，信息必须在某个地方，并且您始终需要一些“参考链”才能在需要时获取它。

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