С интерфейсами и реализациями в отдельных сборках, где Unity должна отображать их в приложении Prism WPF?

В настоящее время я работаю над приложением WPF, используя Prism с Unity. Функциональность модели разделена на несколько проектов библиотеки классов. Для каждой группы проблем у меня есть один проект реализации и один проект, состоящий только из интерфейсов и перечислений. Цель состоит в том, чтобы иметь возможность изменять или полностью заменять DLL реализации, не затрагивая и не изменяя ничего другого в приложении. В этом случае я немного застрял в том, как регистрировать интерфейсы для их реализации без жестких ссылок на оба в приложении верхнего уровня.

Я знаю, что на них нужно будет где-то ссылаться вместе, но не противоречит ли передовой практике, чтобы это происходило в приложении верхнего уровня в загрузчике? Должен ли я вместо этого искать MEF, а не Unity для этой конкретной проблемы?


person Mike    schedule 04.01.2011    source источник
comment
Можете ли вы предоставить пример модели с разделенной функциональностью?   -  person Jon    schedule 05.01.2011
comment
Приложение должно служить проигрывателем для скриптовой автоматизации пользовательского интерфейса. У меня есть проект, который я написал, содержащий интерфейсы для элементов пользовательского интерфейса, которые мы хотим автоматизировать, и отдельный проект, реализующий автоматизацию. Базовая настройка выглядит следующим образом: Scripting.ComponentModel — Scripting — UIAutomation.ComponentModel — UIAutomation — и т. д. Я рассматривал модули Prism, но они больше подходят для композиции пользовательского интерфейса. Я рассматривал сервисный уровень для предоставления состояния и абстрагирования некоторых деталей, но во многих случаях это не принесло бы большой пользы за счет дополнительной сложности.   -  person Mike    schedule 09.01.2011


Ответы (1)


Обычно это делается в модуле, содержащем реализации. Контейнер Unity будет предоставлен с помощью внедрения зависимостей в конструкторе модуля; следовательно, оболочке никогда не нужно фактически регистрировать реализации в интерфейсе. Модуль, содержащий интерфейсы, обычно является инфраструктурной DLL (а не модулем), и, следовательно, на него могут ссылаться модули реализации.

Обратите внимание, что это соответствует рекомендациям Prism относительно разделения интерфейса/реализации между DLL. Они углубляются в это в отношении услуг; хотя я сомневаюсь, что вы найдете какие-либо примеры их использования для моделей или других объектов.

Пример:

using Microsoft.Practices.Unity;
using YourInfrastructureDll;

public sealed class ModuleImplementationA : IModule
{
   private readonly IUnityContainer _container;

   public ModuleImplementationA(IUnityContainer container)
   {
      _container = container;
   }

   public void Initialize()
   { 
      // IYourInterface is defined in the Infrastructure DLL, while YourImplementationA exists in this module
      _container.RegisterType<IYourInterface, YourImplementationA>();
   }
}

Это можно заменить другой реализацией DLL:

using Microsoft.Practices.Unity;
using YourInfrastructureDll;

public sealed class ModuleImplementationB : IModule
{
   private readonly IUnityContainer _container;

   public ModuleImplementationB(IUnityContainer container)
   {
      _container = container;
   }

   public void Initialize()
   { 
      // IYourInterface is defined in the Infrastructure DLL, while YourImplementationB exists in a different module than the first
      _container.RegisterType<IYourInterface, YourImplementationB>();
   }
}
person Matt Jordan    schedule 05.01.2011
comment
Возможно, тогда мое понимание использования модулей было неправильным. Большинство примеров, которые я видел, внедряют менеджеры регионов, что заставило меня поверить, что модули были скорее композицией пользовательского интерфейса. Спасибо - person Mike; 09.01.2011
comment
Модули могут быть для создания пользовательского интерфейса, но они также могут быть для чего угодно. Одна из приятных особенностей Prism заключается в том, что она не навязывает вам это. У вашего уровня доступа к данным могут быть службы, определенные в инфраструктуре, но реализации в модуле (возможно, одна для Oracle, одна для SQL Server и т. д.) — то же самое можно применить к модулю, который просто выполняет бизнес-логику. Это зависит от приложения. - person Matt Jordan; 09.01.2011