Устранение зависимостей Unity в приложении Prism Desktop - PullRequest
Новая
       7

Устранение зависимостей Unity в приложении Prism Desktop

2 голосов
/ 11 февраля 2012

после предыдущего вопроса, который я разместил на StackOverFlow, у меня есть следующая структура проекта для моего настольного приложения Prism.

Библиотека классов : Application.Common -> здесь содержатся все мои DTO и сервисные контракты, которые определены на моем сервисном уровне WCF, что является совершенно другим решением.

Модули: Application.Modules.ServicesModule -> здесь я добавил ссылки на мою реализацию WCF, используя Добавить ссылку на службу. Я также регистрирую реализации моих типов. IMyServiceContract определен в сборке Application.Common, поэтому метод инициализации выглядит следующим образом: - 

public void Initialise()
{
   _container.RegisterType<IMyService, MyServiceClient>(new InjectionConstructor());
}

Наконец, у меня есть другой модуль Application.Modules.FunctionalityModule , в котором есть конструктор, определенный следующим образом 

   public FunctionalityModule(IMyService myService){}

когда приложение пытается разрешить зависимость в FunctionalityModule во время выполнения, возникает следующая ошибка 

Exception occurred while: while resolving.
Exception is: InvalidOperationException - The current type, AccountsSln.Common.ServiceContract.IMyService, is an interface and cannot be constructed. Are you missing a type mapping?

Обычно я видел эту ошибку, потому что зависимость не была зарегистрирована, но в этом случае я знаю, что она есть в ServicesModule. Это как-то связано с регистрацией в разных модулях? Есть ли другие предложения о том, как я могу реализовать структуру своего проекта для поддержки служб WCF в настольном приложении Prism?

Спасибо

Alex

Edit: Поскольку я хотел использовать общую сборку для определения своих сервисных контрактов, у меня возникли проблемы при использовании Add Service Reference. Оказывается, что если вы используете Add Service Reference, сгенерированный код использует метаданные для создания типов на стороне клиента. Они имеют ту же подпись, что и в Общей сборке, но отличаются. Чтобы дать мне возможность использовать контракты в Общей сборке, я черпал вдохновение из этого поста http://xaml.geek.nz/working-slightly-smarter-with-wcf. Это заставило меня начать в правильном направлении, но я думаю, что мне нужно будет сделать код более подходящим для производственной среды.

Ответы [ 2 ]

1 голос
/ 12 февраля 2012

Проблема в том, что вы не указали требуемое сопоставление интерфейса с типом реализации. (Я предпочитаю использовать UnityContainerExtensions). 

unityContainer.RegisterType < IStudentSearchService, StudentSearchService > ();

Вам также необходимо указать зависимости модуля. Ваш FunctionalityModule зависит от ServicesModule. Как это сделать, зависит от того, как создается ModuleCatalog. Так что либо; в Bootstrapper CreateModuleCatalog используйте moduleCatalog.AddModule или украшайте IModules с ModuleAttribute и ModuleDependencyAttribute, если используете DirectoryModuleCatalog.

Конечно, UnityContainer можно настроить через файл app.config.

0 голосов
/ 15 февраля 2012

Сгенерированные прокси-классы службы являются частичными классами. Возможно, вы сможете просто заставить их наследовать от IMyService в общей сборке, добавив что-то вроде следующего в проект, где ссылки на сервисы: 

using Application.Common.IMyService;

namespace Application.Modules.ServicesModule
{
    public partial class MyServiceClient : Application.Common.IMyService
    {
    }
}
...