Что такое лучшая практика при разработке SOA веб-сервисы WCF?
См. Этот блог, в котором показано, как транслировать видеофайл с использованием aspnet webapi с помощью PushStreamContent .
https://www.strathweb.com/2013/01/asynchronously-streaming-video-with-asp-net-web-api/
https: //www.c-sharpcorner.com/article/asynchronous-videos-live-streaming-with-asp-net-web-apis-2-0/
4 ответа
XML обычно имеет тенденцию быть camelCased. WSDL и XML Использование схемы camelCasing и для элементов и для атрибутов, например, проверьте синтаксис и схему.
Почему SOAP был определен по-другому, я не знаю, но это использует PascalCasing для элементов и camelCasing для атрибутов, проверьте здесь.
Similary, большая часть WS* спецификации (возможно, все) используют PascalCasing для элементов и атрибутов, видят здесь. XML-схема является агностиком о конвенциях типов, которые она определяет для XML.
Thomas Erl пишет много важных книг по SOA включая "Архитектуру Для обслуживания широкого круга запросов". В Главах 13 и 15 он обеспечивает много примеров XML различных частей типичных транзакций. Это определяет типы и элементы объекта в использовании XML-схемы PascalCasing, который приятно соответствует нормальным шаблонам C# для именования свойства и класса. Таким образом WCF значения по умолчанию уже тесно соответствуют стандартам.
Относительно фактического именования сообщения некоторые конвенции используют camelCasing, и другие используют PascalCasing, таким образом, мое предпочтение состоит в том, чтобы соответствовать основным потребностям языка, который в WCF случаем является PascalCasing. И WCF значения по умолчанию соответствуют некоторым примерам того, как запрос и ответное сообщение должны быть записаны, некоторые примеры здесь.
Таким образом, единственный нерешенный вопрос является теперь основным вопросом того, сколько стандартизировать вокруг использования OperationContract, DataContract, и/или MessageContract.
Определение DataContract только, когда Вы имеют составной тип (в XSD язык), имеет смысл, и я склонен думать YAGNI (Вы не Собираетесь Потребность Он), как указано Terry, верный выбор, но Эрл, кажется, предлагает намного больше процесса интенсивная версия, таким образом, я все еще не уверен лучший подход для использования в качестве моего выбора по умолчанию (основная часть вопроса).
Я думаю, что это честно зависит от сценария. Если Вы просто обмениваетесь простыми типами [т.е. строка], OperationContract, конечно, приемлем.
Необходимо использовать MessageContract, когда Вы хотите изменить формат сообщения, и DataContract должен быть усилен, когда Вы хотите выразить Составной тип, такой как адрес.
YAGNI приходит на ум здесь.
Я говорю, не переделывают, делают это при получении, также представляют себе смотреть в будущее. WCF является уже приятно дружественный SOA. Я говорю, в целом, придерживайтесь значений по умолчанию и быть осторожными относительно связи, пока у Вас нет определенной потребности сделать что-то тщательно продуманное.
всегда рекомендуется не иметь нескольких параметров в контракте операции, всегда иметь тип, который включает все необходимые параметры, это поможет в долгосрочной перспективе. Ваши существующие клиенты не сломаются, когда вы добавите новый необязательный параметр.
Я работаю в группе бизнес-интеграции, где мы довольно регулярно интегрируемся с другими компаниями (AT&T, Cox, Exxon ...) и никогда не видел Интернета вызов службы, который принял более одного параметра.