Управление конфигурацией WCF, когда ваши ссылки на сервисы абстрагируются от API - PullRequest
Новая
       15

Управление конфигурацией WCF, когда ваши ссылки на сервисы абстрагируются от API

1 голос
/ 18 февраля 2011

У меня есть некоторая логика домена через службы WCF. Вместо того, чтобы явно писать вызовы прокси WCF и т. Д. В моем веб-приложении MVC, я обернул ссылки на службы WCF в их собственный проект - MyProject.BizLogic.Endpoint - и затем добавил ссылку на этот проект в мое веб-приложение.

Это отлично подходит для поддержания чистоты и читаемости кода контроллера - конечная точка предоставляет интерфейс ICrmSystem с красиво абстрагированными методами, такими как RetrieveCustomerDetails (int customerId), а затем внутри класса конечной точки, который помещается в CustomerQuery DTO и запускается на удаленном Сервис CustomerQueryHandler. Для изолированного тестирования вы просто макетируете ICrmSystem и тестируете методы контроллера в сравнении с имитируемой реализацией.

Дело в том, что WCF требуется много загадочной и деликатной конфигурации, и в настоящий момент мне нужно иметь все привязки system.serviceModel и конфигурации клиента в файле web.config моего веб-приложения.

Есть ли более чистый способ управления этой конфигурацией - предпочтительно как часть модуля абстракции Endpoint, чтобы веб-разработчикам даже не нужно было знать, что WCF происходит за кулисами? Могу ли я как-то вставить ссылку на файл конфигурации Endpoint в мое веб-приложение? Или управлять конфигурацией WCF программно, а не декларативно?

Спасибо

Dylan

Ответы [ 2 ]

2 голосов
/ 21 февраля 2011

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

Мой Web.config теперь содержит: 

<system.serviceModel>
    <bindings configSource="services/bindings.config" />
    <client configSource="services/myservice.endpoint.config" />
</system.serviceModel>

, что означает фактические конечные порты / протоколы / и т. Д.могут быть изолированы в своей собственной подпапке.Эта папка теперь настроена как внешняя (подмодуль) в нашей VCS, так что если мы изменим часть инфраструктуры - скажем, перенесем службу на другой физический сервер - мы можем обновить конфигурацию, зафиксировать эти изменения, обновить любой проект с помощьюзависимость от этих разделов конфигурации и избегать необходимости вручную обновлять файлы конфигурации в нескольких развернутых приложениях.

Единственное предостережение заключается в том, что IIS не будет обнаруживать изменения в этих файлах, как это происходит с основным Web.config, поэтомупосле его изменения вам нужно либо коснуться web.config, либо перезапустить веб-приложение.Кроме того, он работает довольно хорошо.

1 голос
/ 18 февраля 2011

Держите это в конфиге. Меня спасли слишком много раз, так как я мог мгновенно указывать на службы в другом месте или добавлять новые варианты поведения на лету слишком много раз, чтобы считать. Кодировано = Скомпилировано = Труднее изменить

...