Здание графа объектов DI - разделение логики и графика конструкции
Для удаления чего-то, не сохраняя его в регистре можно использовать "регистр черной дыры":
"_d
, Конечно, Вы могли также использовать любой из других регистров, которые не содержат ничего, чем Вы интересуетесь.
2 ответа
Один из вариантов - настроить TableFactory , который знает поставщика и читателя запросов, и ему нужно знать только имя таблицы. Затем вы можете передать фабрику в TableManager . С другой стороны, TableManager звучит так, как будто он, вероятно, должен быть самой фабрикой - и в этом случае простому нужны провайдер и считыватель, даже если это может быть неочевидно для начнем с, учитывая, что он просто передает их.
Я согласен, что это становится немного беспорядочным - в основном, если что-то «глубоко в дереве» (и динамически создаваемое) требует части информации, тогда все, что создает это, нуждается в этой информации - и все, что создает этот создатель, нуждается в этом и т.д. Не будьте осторожны (а иногда и так).
В зависимости от вашей структуры DI, вы можете настроить фабричный объект в контейнере, а затем попросить его создать новый экземпляр во время выполнения. Это означает, что ваш код, конечно же, связан с платформой DI - это случай колебаний и окольных путей. По сути, информация должна быть где-то , и вам всегда понадобится какая-то «цепочка ссылок», чтобы добраться до нее, когда она вам понадобится.
Извините, что не могу смотреть на нее лучше, но даже если эти идеи вам не очень помогают, по крайней мере, вы знаете, что вы не одиноки :)
Это означает, что ваш код, конечно же, связан с платформой DI - это случай колебаний и окольных путей. По сути, информация должна быть где-то , и вам всегда понадобится какая-то «цепочка ссылок», чтобы добраться до нее, когда она вам понадобится.Извините, что не могу смотреть на нее лучше, но даже если эти идеи вам не очень помогают, по крайней мере, вы знаете, что вы не одиноки :)
Это означает, что ваш код, конечно же, связан с платформой DI - это случай колебаний и окольных путей. По сути, информация должна быть где-то , и вам всегда понадобится какая-то «цепочка ссылок», чтобы добраться до нее, когда она вам понадобится.Извините, что не могу смотреть на нее лучше, но даже если эти идеи вам не очень помогают, по крайней мере, вы знаете, что вы не одиноки :)
Не могли бы вы добавить поставщика и ридер в качестве параметров в OpenTable () ?
Кто звонит OpenTable () ? Знает ли вызывающий поставщик провайдера и ридер , чтобы передать их методу?