Контракт-первый SOA с WCF

этот вопрос является скорее зондом, чтобы узнать, что люди делают в сообществе, в практических ситуациях, чем специально целевой вопрос. Я искал довольно широко об этом, и хотя я нашел много блоггеров, выступающих за дизайн услуг по контракту и некоторые комментарии, поддерживающие их, мне еще предстоит найти много практической информации о реализации контракта-сначала с WCF, плюсы и минусы этого в реальной среде и т. д. Я недавно сделал некоторые обширные исследования SOA, в основном через книги Томаса Эрла, и одна из основных концепций, которую он защищает,-это дизайн по контракту.

мои вопросы таковы:

  1. как вы подходите к контрактному дизайну службы с .NET и WCF?
  2. есть ли другие инструменты, кроме svcutil, которые могут генерировать как клиент, так и сервис из контракта? (Все, что интегрируется с VS, было бы идеальным)
  3. какие реальные профи у вас есть столкнулся с контрактным дизайном и wCF?
  4. какие реальные минусы вы столкнулись с контрактным дизайном и WCF?

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

EDIT:

в то время как WCSF решил мои насущные потребности, узнав о Протокол Буферы и Фабрика Услуги как интригует инструменты, которые я уверен помогут мне в будущем.

5 ответов


WSCF предоставляет инструмент контракта с интеграцией VS. Checkitout. (бесплатно)

по состоянию на 6 июля, есть бинарная версия с программой установки.


Я использую подход контракта, как правило (но не всегда), используя одно и то же представление типа на каждом конце.

на самом деле, для использования WCF вам не нужны специальные прокси и т. д.; Вы можете использовать свои обычные типы .NET с обоих концов и не использовать svcutil.exe на всех. Получить рабочую службу так же просто, как добавить " ABC " в файл конфигурации и использовать что-то вроде:

public sealed class WcfClient<T> : System.ServiceModel.ClientBase<T>
    where T : class
{
    public T Service { get { return base.Channel; } }
}

теперь вы можете использовать:

using(var client = new WcfClient<IMyService>()) {
    int i = client.Service.SomeMethod("abc");
}

и все, что у вас есть на клиент (и сервер) - это ваш IMyService интерфейс.


для других инструментов; protobuf-net-это реализация API "буферов протокола" Google, который имеет DSL для описания данных и услуг "сначала контракт" (и портативный/совместимый) способ - например (a .proto file):

message SearchRequest {
  required string query = 1;
  optional int32 page_number = 2;
  optional int32 result_per_page = 3;
}
message SearchResponse {
  repeated string result = 1; 
}
service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}

инструмент protobuf-net (который я поддерживаю) включает утилиту "protogen" для преобразования этого DSL в C# / VB; и один из вариантов (для C#, по крайней мере - мне нужно будет проверить VB) должен испускать полную реализацию прокси-сервера WCF (с вашим выбором методов синхронизации или асинхронности); очень похож на svcutil - но (из-за отношения protobuf-net) он включает пользовательский [ProtoBehavior] атрибут в operation-contracts, так что он использует сериализатор protobuf-net вместо DataContractSerializer (быстрее и эффективнее, но разные).

для интеграции VS; я работаю именно над этим (доказательство).


Я предпочитаю разработку по контракту. Я использовал Фабрика Обслуживания для этой цели. Это позволило мне генерировать как сервис, так и клиентский код без настройки.

С настройка, мы также смогли генерировать объекты передачи данных, соответствующие объектам Entity Framework, вместе с кодом для перевода с одного на другой; автоматическое ведение журнала исключений; и HTML-документация сервисы.

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


в WCF у вас есть некоторое разнообразие в том, как выглядит "контракт-первый". Вы можете сделать "сначала контракт кода", где ваши данные и контракты на обслуживание выражаются как типы .NET с правильной разметкой атрибута. Можно начать с WSDL и создать контракты на обслуживание и данные, или можно начать со схемы XML для контракта на данные и выразить контракт на обслуживание в виде кода. Какой путь вы идете на самом деле зависит от характера контракта и как он будет использоваться.

Если вы реализация чего-то в спецификации WSDL, код gen из WSDL является очевидным выбором, и генерирование из рук не такое уж большое дело. Вы можете запустить генерацию из события сборки проекта (или попасть в msbuild), если хотите, чтобы изменения в файле WSDL распространялись немедленно.

Если у вас есть существующая схема (XSD), которую вы хотите использовать в качестве контракта данных, или предпочитаете разрабатывать контракт данных таким образом для облегчения повторного использования на других платформах, вы можете создавать типы из схемы с помощью XSD-файл.exe (или альтернатива 3rd). В этом случае вы будете использовать XML-сериализуемые типы в своем коде-ориентированном сервисном контракте, например этой: .

Если вы разрабатываете клиентов и серверы самостоятельно в .NET, и ваши клиенты могут либо получить ваши сборки контракта, либо счастливы генерировать клиентов из метаданных службы (например, WSDL), моделирование ваших контрактов в коде-отличный опыт. Используя схему "известные типы", вы можете поддерживать модели наследования в данные контракта, который может быть очень мощным. Вы можете полностью пропустить создание кода клиента (как указано в других ответах), напрямую сославшись на сборку контракта в клиенте. Это очень продуктивно и элегантно, но вы должны знать, что вы можете создавать проблемы взаимодействия, если вы слишком фантазии.


то, как мы это делаем, описано в этом видео:

http://www.dnrtv.com/default.aspx?showNum=103

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

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