代码之家  ›  专栏  ›  技术社区  ›  Nathan W

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

  •  6
  • Nathan W  · 技术社区  · 16 年前

    对不起,如果这是一个很基本的问题,但我一直很理解。我真的很喜欢DI的想法,它对我的测试非常有帮助,但是我觉得我遇到了一些困难。所以我有两种类型:

     Table
     TableManager
    

    现在,表对象上有一个这样的构造函数:

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

    现在,表对象几乎只使用那些对象,所以遵循规则,您需要什么,我将它们传入。现在,我的TableManager对象用于打开和关闭ETC表。它只需要一个ITableCommandRunner,所以我在构造函数中传递它。

     TableManager(ITableCommandRunner tablrunner)
    

    好的,这很好,但是在tablemanager.openttable命令中,我需要调用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的构造函数中,这不会违反“将对象传递给内部类型,而不是真正使用它们”。

    我不太确定我是怎么做到的。有人能帮我吗?

    我只是不确定如何将对象结构和逻辑分开。

    2 回复  |  直到 15 年前
        1
  •  2
  •   Jon Skeet    16 年前

    一个选项是配置 TableFactory 哪一个 了解查询提供程序和读卡器,只需要知道表名。然后你可以把工厂交给 TableManager . 另一方面,A 制表员 听起来它可能需要是工厂本身-在这种情况下,它很简单 需要提供者和读者,尽管一开始可能并不明显,但考虑到它只是传递给他们。

    我同意它会变得有点混乱——基本上,如果“树的深处”(和动态创建的)需要一条信息,那么任何创建它的东西都需要该信息——以及任何创建创建者需要它的东西,等等。如果你不小心的话(有时甚至是这样),它肯定会变得一团糟。

    根据DI框架的不同,您可能能够在容器中配置类似工厂的对象,然后要求在执行时创建一个新实例。这意味着您的代码将与DI框架结合在一起——这是一种摆动和迂回的情况。基本上信息必须 在某处 当你需要的时候,你总是需要一些“参考链”来找到它。

    很抱歉,对它没有一个更乐观的看法,但即使这些想法对你没有太多帮助,至少你知道你不是一个人。

        2
  •  0
  •   dss539    15 年前

    你能加上吗? provider reader 作为参数打开 OpenTable() ?

    谁在呼唤 OpenTable() ?打电话的人知道 供应商 读者 这样它就可以把它们传递给方法了?