Принцип инверсии зависимостей
В книге "Внедрение зависимостей на платформе .NET" написано, что принцип инверсии зависимостей диктует обязательное распространение абстракций с их собственными модулями.
Полный отрывок:
Если принцип инверсии зависимостей диктует обязательное распространение абстракций с их собственными модулями, не нарушает ли интерфейс доменного уровня IProductService этот принцип? К тому же IProductService потребляется уровнем пользовательского интерфейса, но реализован, как показано на рис. 3.12, доменным уровнем. Да, это нарушение принципа инверсии зависимостей. Если бы мы были заинтересованы в исправлении этого нарушения, то нужно было бы убрать IProductService из доменного уровня. Но перемещение IProductService на уровень пользователь ского интерфейса сделает наш доменный уровень зависимым от него. Поскольку доменный уровень является центральной частью приложения, нам не хотелось бы, чтобы он зависел от чего-либо еще. Кроме того, эта зависимость не позволила бы впоследствии заменить уровень пользовательского интерфейса. Все это означает, что для устранения нарушения в нашем решении нужны еще два дополнительных проекта: один для изолированного уровня пользовательского интерфейса без точки входа (Composition Root), а другой — для абстракции IProductService, которой владеет уровень пользовательского интерфейса. Но сугубо из прагматичных соображений для данного примера мы решили не следовать по этому маршруту, оставив нарушение в покое.
В книге не написано конкретного решения этой проблемы, а лишь говорится каким способом ее можно решить, а именно:
- Создать проект для изолированного уровня пользовательского интерфейса без точки входа (Composition Root)
- Создать проект для абстракции IProductService, которой владеет уровень пользовательского интерфейса
Проблема в том, что я не очень понимаю как реализовать этот предложенный способ