Контейнер IOC и примитивы при создании оболочки

Я пытаюсь создать оболочку интерфейса для своего контейнера IOC, чтобы не зависеть от конкретного контейнера. Моя проблема в том, что некоторые из классов обслуживания, которые у меня есть, имеют идентификатор компании, который является строкой. Я хочу создать общие методы интерфейса, например

T Resolve<T>() где T - служебный интерфейс.

Прямо сейчас я использую StructureMap за кулисами и знаю, принимает ли конкретный конструктор идентификатор компании, поэтому я сделаю что-то вроде этого:

ObjectFactory.With("companyid").EqualTo("someCompanyID").GetInstance<ICompanyService>();

Я оборачиваю такой вызов в метод интерфейса: ICompanyService GetCompanyService(string companyID)

В моем нынешнем виде приложение должно инициализировать конфигурацию StructureMaps, а конкретный класс, который передает обратно службы, должен много знать о конструкторах. Я бы хотел, чтобы этого не происходило и чтобы обертка была универсальной. Есть ли хороший способ без добавления companyID к каждому методу интерфейса?


architecture c# inversion-of-control structuremap
person CSharpAtl    schedule 08.12.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Лично меня не волнует абстрагирование от MSUnity (моего предпочтительного контейнера IOC). Для меня это слишком далеко. Похоже, вы используете специфические особенности структурной карты, которые усложнят абстракцию.

Известно ли вам о проекте CommonServiceLocator? У этого есть два основных метода:

protected override object DoGetInstance(Type serviceType, string key) { }
protected override IEnumerable<object> DoGetAllInstances(Type serviceType) {}

При условии, что вы будете их использовать, вы можете легко переключиться. Вот дополнительная информация.

person RichardOD    schedule 08.12.2009
comment
Я немного отвлекся от SM, но не полностью. Я смотрю на какой-то открытый исходный код, который сделал оболочку, но он не учитывает примитивы в ctors. - person CSharpAtl; 08.12.2009
comment
@ CSharpAtl - пересмотрите свой дизайн. Подобные фреймворки должны работать с наименьшим общим знаменателем. Вам нужно решить, важнее ли возможность выключить IOC, чем возможность использовать определенные функции StructureMap. - person RichardOD; 08.12.2009
comment
+1 Я слышал вас .... просто пытался работать над этой проблемой, и глядя на MVC Turbine, которая создает что-то подобное, снова заставляет задуматься. - person CSharpAtl; 08.12.2009

arrow_upward
0
arrow_downward

В MvcContrib есть класс DependencyResolver.

С другой стороны, большую часть времени я просто ссылаюсь на контейнер IoC только из своего проекта приложения. Например, я просто настраиваю свои классы для внедрения ctor, и когда мне нужно получить экземпляр (в проекте приложения), я просто прошу об этом контейнер IoC. Контейнер IoC может беспокоиться о заполнении аргументов ctor, но объекты не знают о контейнере IoC. Таким образом, мой проект приложения - единственный проект, которому необходимо обновить контейнер IoC.

person pattersonc    schedule 08.12.2009