Вы можете настроить WCF из кода, не создавая больше связей, чем при использовании файлов конфигурации.
Мне нравится использовать следующие разделы:
Сервер:
- Одна сборка для ваших контрактов данных (модели / DTO).
- Одна сборка для ваших сервисных контрактов (интерфейсы WCF).
- Одна сборка для реализации вашего сервиса.
- Одна сборка для вашей логики создания хоста службы. Эта сборка будет содержать класс (WCFHostsLoader), который создает экземпляры хостов службы для всех ваших конечных точек.
- Одна программа для подключения хоста WCF. Под ASP.Net это может быть Globas.asax. В Globas.asax вы бы вызвали WCFHostsLoader.Configure ().
Клиент:
Клиент - это отдельная тема. Вы подразумевали, что клиент должен совместно использовать те же сборки (модели), что и сервер. Хотя это возможно (это то, что мы делаем в нашем проекте); это не обязательно.
Вариант 1 - использовать одну и ту же модель сборки и контракта на обслуживание. Насколько мне известно, это лучший подход, если клиентское приложение написано в .Net (и написано вами или стороной, которой вы можете предоставить две требуемые сборки). Основным преимуществом является то, что на клиенте вы не получаете кучу некрасиво сгенерированных классов. Я также думаю, что этот подход более элегантный. Посмотрите на шаблон GoF Proxy . В шаблоне «чистый прокси» параметры (модели) не передаются прокси-службе.
Варианты 2 - использовать набор прокси-классов, сгенерированных из WSDL-сервера. Я думаю, что это гораздо более распространенное явление, потому что a) Visual Studio Add Service Reference делает это легко. б) Если клиент не .Net, это единственный вариант. Если вы используете классы, сгенерированные Visual Studio Add Service Reference, у вас могут возникнуть трудности с попыткой взять под контроль процесс создания фабрики каналов, чтобы настроить все из кода, а не из файлов конфигурации (я никогда не пытался это сделать). Могут существовать другие инструменты для генерации прокси-классов, которые будут более дружественными к конфигурации кода.
Надеюсь, это поможет