SOA по контракту с WCF

StackOverflow https://stackoverflow.com/questions/1047161

  •  20-08-2019
  •  | 
  •  

Вопрос

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

Мои вопросы заключаются в следующем:

  1. Как вы подходите к проектированию сервисов на основе контрактов с помощью .NET и WCF?
  2. Существуют ли другие инструменты, кроме svcutil, которые могут генерировать как клиент, так и сервис по контракту?(Идеально было бы все, что интегрируется с VS)
  3. С какими реальными плюсами вы столкнулись при проектировании на основе контракта и wCF?
  4. С какими реальными недостатками вы столкнулись при проектировании на основе контракта и WCF?

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

РЕДАКТИРОВАТЬ:

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

Это было полезно?

Решение

ВССК предоставляет инструмент, ориентированный на контракты, с интеграцией VS.Оформить заказ.(бесплатно)

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top