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

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

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

Как вы подходите к дизайну контракта с первым .NET и WCF?
Существуют ли другие инструменты, кроме svcutil, которые могут генерировать как клиент, так и сервис из контракта? (Все, что интегрируется с VS, было бы идеальным)
С какими профессионалами в реальном мире вы столкнулись с дизайном контракта и wCF?
Какие реальные минусы вы столкнулись с контрактом-первым дизайном и WCF?

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

EDIT:

В то время как WCSF решил мои непосредственные потребности, узнал о Буферы протокола и Сервис Factory - оба интригующих инструмента, которые, я уверен, помогут мне в будущем.

Ответ 1

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

По состоянию на 6 июля существует двоичный выпуск с программой установки.

Ответ 2

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

Собственно, для использования 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-интерфейсов API-протоколов Google, которая имеет DSL для описания данных и сервисов в режиме "первый контракт" (и переносимый/интероперабельный) - например (файл .proto):

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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