Я намочил ноги с DI/МОК и MEF в частности.
У меня есть веб-приложение, которое имеет два типа частей (возможно, больше когда-нибудь) определенный интерфейсами, которым нужен доступ к целой среде. Приложение имеет список с конкретными реализациями для каждого типа, составленного MEF.
Среда состоит из:
Как я могу поместить Интерфейсные определения в отдельный блок, и в то же время указывают инжекцию среды?
Очевидно, я не могу только сослаться на основной блок, потому что это должно сослаться на блок контракта, и я не могу создать циклическую ссылку.
Кажется, что я должен создать интерфейс для каждого из классов среды и их общедоступные типы и так далее... Должен быть лучший путь?!
Возможно, я также пропускаю очевидный больший дефект здесь, если кто-либо мог бы указать на это для меня?
Если вы хотите отделить свои абстракции от их реализаций (всегда достойная цель), вы должны определить эти абстракции в их собственной сборке.
С точки зрения реализации, с этим легко справиться, потому что вам нужно ссылаться на абстракции для их реализации. Нет никакого способа обойти это независимо от того, используете вы MEF или нет, так что так было всегда:
[Import(typeof(IFoo))]
public class MyFoo : IFoo { }
Однако, как вы говорите, это означает, что вы не можете ссылаться на свой корень композиции из библиотеки абстракций . Однако так и должно быть, потому что абстракции не должны беспокоиться о том, как они будут скомпонованы.
Другими словами, вы должны реализовать композицию зависимостей вне библиотеки абстракций. Хорошим кандидатом для этого является сам исполняемый файл, тогда как вы должны хранить все свои конкретные реализации в одной или отдельных библиотеках.
Библиотека абстракции не будет иметь ссылок, в то время как и потребители, и разработчики должны будут ссылаться на нее, поэтому граф зависимостей может выглядеть следующим образом:
Composition Root --> Abstractions <-- Implementations
Где стрелки обозначают ссылку.