Оставаться открытым с контейнерами DI / IoC - PullRequest
1 голос
/ 08 февраля 2010

Я участвую в нескольких проектах с открытым исходным кодом, которые в совокупности обеспечивают основу для разработки приложений. У меня вопрос, какой механизм (а) я должен предоставить для их интеграции друг с другом?

На концептуальном уровне ответ ясен - DI / IoC. «Единственная» проблема - решить, какая именно. В нескольких установках мы использовали StructureMap, но затем появился пользователь, который хотел только один из компонентов и хотел NInject.

Итак, чтобы уточнить вопрос, как мне следует строить свои компоненты так, чтобы они могли быть интегрированы друг с другом (и третьей стороной) с использованием различных контейнеров DI / IoC.

Лучшее, что я мог придумать, это разделить весь код интеграции на отдельные проекты и затем создать проект для каждого поддерживаемого контейнера IoC, но это звучит подозрительно, как квадрат IoC.

Какие-нибудь яркие идеи? или я просто слишком много думаю?

P.S. для любопытных: Нджанго ; Bistro ; Сервер рабочих процессов

Ответы [ 2 ]

2 голосов
/ 08 февраля 2010

См. этот очень связанный вопрос (почти дубликат).

Для вдохновения об интеграции нескольких проектов, сохраняя их независимость, см. Castle Project .

2 голосов
/ 08 февраля 2010

Пока вы разрабатываете повторно используемые компоненты, вы можете реализовать их в DI-дружественном способе, даже не ссылаясь на какой-либо конкретный DI-контейнер .

Только когда вам нужно составить реальное работающее приложение, вам нужен DI-контейнер, но, как я понимаю, вы разрабатываете фреймворк, и лучше всего поддерживать его в DI-нейтральном.

...