Я полагаю, что это может говорить о некоторых одинаковых принципах, но на разных уровнях детализации. Однако я бы все равно рассматривал Deverdency Inversion как нечто, что стоит само по себе.
В первом случае рассмотрим этот пример - в простой многоуровневой архитектуре у вас может быть уровень представления, встроенный в JavaScript, уровень бизнес-логики, встроенный в Java, и уровень данных в SQL Server. Эти слои могут быть разработаны различными группами людей. Уровень представления знает, как выполнять вызовы API на уровне бизнес-логики, но не наоборот. Уровень бизнес-логики знает, как читать / записывать на уровень базы данных и обратно, но не наоборот. Различие здесь происходит на высоком уровне - вы можете даже назвать это концептуальным.
Во втором случае вы хотите предотвратить сценарии, в которых предположительно универсальный код зависит от конкретных реализаций - и на этом этапе я рассматриваю его как относительно низкоуровневую проблему, которая попадает в область действия конкретного приложения (то есть в коде). не концептуально, как в предыдущем примере). Если у вас есть код, который пишет в базу данных, но вы хотите поддерживать различные реализации - например, MySQL и SQL Server, где каждый из них может иметь некоторые специфические сложности, не делают вызывающий код явно зависимым ни от одного из них - абстрагируют от сложности интерфейс. Это то, к чему обращается Принцип обращения зависимостей (см. Ниже).
public class UserService {
public UserRepository repository;
public void setUserRepository(UserRepository repository) {
this.repository = repository; //Is this a MySqlRepository or a SqlServerRepository? We don't care - the dependency is managed outside and we can change it without changing this class.
}
public void persistUser() {
this.repository.persist(user); //We just care about the abstraction - the interface.
}
}
Вы ищете свойство ItemContainerGenerator. Каждый ItemsSource
имеет экземпляр ItemContainerGenerator. Этот класс имеет следующий метод, который мог бы заинтересовать Вас: ContainerFromItem (экземпляр объекта).
После того как у Вас есть дескриптор к ListBoxItem
, можно идти вперед и просмотреть логическое и визуальное дерево. Проверьте Логического Древовидного Помощника и Визуального Древовидного Помощника.
Как Andy, сказанный в комментариях, просто потому что объект существует в Вашем наборе, не означает, что контейнер был сгенерирован для него. Любой вид виртуализации сценария панели поднимет этот вопрос; UIElements будет снова использован через различные объекты. Будьте осторожны с этим также.