DI объект построения графа - разделительная логика и график построения

Question

Извините, если это действительно основной вопрос, но это действительно было для меня. Мне очень нравится идея DI, это действительно помогает мне с моим тестированием, но я ударил немного кирпичной стены, я думаю. Поэтому у меня есть два типа:

Table 
TableManager 

Теперь табличный объект имеет конструктор по нему так:

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

Теперь объект таблицы в значительной степени использует только те объекты, так следуя правилу, что вы просите что вам нужно, я передаю их. Теперь мой объект TableManager используется для открытия и закрытия таблиц. Единственное, что ему нужно, это ITableCommandRunner, поэтому я передаю это в конструкторе.

TableManager(ITableCommandRunner tablrunner) 

Хорошо, что это нормально, но в TableManager.OpenTable команде мне нужно вызвать открытую таблицу на вводе команды ITableCommandRunner, а затем построить новый объект таблицы передать обратно.

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 - это случай качелей и каруселей. В основном информация должна быть где-то, и вам всегда понадобится «цепочка ссылок», чтобы добраться до нее, когда вам это нужно.

К сожалению, не имеют перспективы на веселее это, но даже если эти идеи не очень поможет вам по крайней мере, вы знаете, что вы не одиноки :)

Answer 2

Не могли бы вы добавить provider и reader в качестве параметров по OpenTable()?

Кто звонит OpenTable()? Означает ли вызывающий объект provider и reader, чтобы он мог передать их методу?