Как использовать Unity для реализации простого механизма публикации компонентов - PullRequest
Новая
       6

Как использовать Unity для реализации простого механизма публикации компонентов

1 голос
/ 17 июля 2010

В нашем проекте мы реализовали простое средство, позволяющее одной стороне публиковать динамические компоненты, а третьим - использовать их. Я хотел бы свернуть нашу внутреннюю реализацию и взять что-то готовое с полки. Поскольку наши ребята из UI уже используют Caliburn + Prism + Unity, я решил использовать Unity (кажется, странно делать две разные реализации контейнера IoC).

Ради вопроса вот игроки:

  1. Типы сущностей (A, B)
  2. Предприятия предприятий (FactoryA, FactoryB)
  3. Менеджер сущностей (Manager)
  4. Клиент

На данный момент Manager имеет RegisterFactory(IFactory) API, который является единственным способом регистрации новых типов сущностей - его необходимо вызывать, передавая новый экземпляр фабрики сущностей.

Однако явные вызовы этого метода со стороны клиента редки, потому что Manager запускает наш внутренний движок, который проверяет все сборки в определенной папке и загружает те, которые объявляют определенный атрибут уровня сборки. Атрибут указывает тип конкретной фабрики сущностей, так что механизм может создать его экземпляр (используя Activator.CreateInstance) и вызвать API RegisterFactory.

Кроме того, движок контролирует папку и знает, как загружать новые сборки на лету.

Например, если C - это новый тип сущности, реализованный в сборке Foo.dll, тогда сборка должна иметь атрибут уровня сборки, например: 

[assembly: PublishEntity(typeof(FactoryC))]

Затем размещение Foo.dll в этой специальной папке приводит к тому, что движок:

  1. проверьте его и найдите там соответствующий экземпляр атрибута уровня сборки
  2. Создать новый FactoryC экземпляр, используя отражение
  3. Вызвать Manager.RegisterFactory, передав в качестве аргумента экземпляр FactoryC.

Дело в том, что я хочу использовать Unity для достижения той же функциональности.

Есть идеи?

Спасибо.

EDIT

Требуются оба типа: Manager и Factory. То, что мне интересно исключить, - это специальное средство регистрации - атрибут, метод RegisterFactory и механизм, который сканирует папку и загружает соответствующие сборки. Теперь я понимаю, что единства может быть недостаточно. Мне интересно узнать о бесплатных решениях, которые удовлетворят наши потребности. Я просто хочу использовать что-то хорошо известное и проверенное, желательно что-то, что стремится быть стандартом.

1 Ответ

0 голосов
/ 17 июля 2010

Unity требует настройки типа, либо в конфигурации приложения, либо в процессе сборки. Ваш текущий двигатель добавляет ценность, делая сборку зондирования. Единство просто не делает этого.

Единственной целью, которую я вижу в обслуживании Unity, является замена вашего менеджера и, возможно, классов Factory, позволяя Клиенту разрешать сущности (и фабрики?) С помощью Unity. Вы можете продолжать разрешать вашему движку горячую настройку Unity с найденными сборками.

...