Сейчас я управляю командой из примерно 15 разработчиков, и мы застряли на этапе выбора технологии, когда команда разбита на две совершенно противоположные команды, обсуждающие вопрос об использовании WCF и веб-API.
Команда A, которая поддерживает использование Web API, выдвигает следующие причины:
- Web API - это просто современный способ написания сервисов ( Википедия )
- WCF - это издержки для HTTP. Это решение для TCP, Net Pipes и других протоколов.
- Модели WCF не являются POCO из-за [DataContract] & [DataMember] и этих атрибутов
- SOAP не так удобен для чтения и удобен, как JSON
- SOAP - это нагрузка на сеть по сравнению с JSON (транспорт по HTTP)
- Нет перегрузки метода
Команда B, которая поддерживает использование WCF, говорит:
- WCF поддерживает несколько протоколов (через конфигурацию)
- WCF поддерживает распределенные транзакции
- Для WCF существует множество хороших примеров и историй успеха (хотя Web API еще молод)
- Дуплекс отлично подходит для двусторонней связи
Эта дискуссия продолжается, и я не знаю, что делать сейчас. Лично я думаю, что мы должны использовать инструмент только для его правильного места использования . Другими словами, нам лучше использовать Web API, если мы хотим предоставить сервис через HTTP, но использовать WCF, когда речь идет о TCP и Duplex.
Выполняя поиск в Интернете, мы не можем получить надежный результат. Существует много постов для поддержки WCF, но, напротив, мы также находим жалобы на это. Я знаю , что природа этого вопроса может показаться спорным, но нам нужны хорошие советы , чтобы решить. Мы застряли в такой ситуации, когда случайный выбор технологии может заставить нас пожалеть об этом позже. Мы хотим выбирать с открытыми глазами.
Наше использование будет в основном для веба, и мы будем предоставлять наши сервисы через HTTP. В некоторых случаях (скажем, от 5 до 10 процентов) нам могут понадобиться распределенные транзакции.
Что мне теперь делать? Как мне вести эту дискуссию конструктивно?
Ответы:
Когда у обеих сторон есть веские аргументы и мнения по этому вопросу слишком сильны, чтобы прийти к консенсусу, вы, как руководитель, должны принять решение и прекратить дискуссию. В противном случае он просто превратится в круги и еще больше укрепит позиции всех участников. Чем дольше вы ждете, тем труднее проигравшей стороне признать поражение и продуктивно работать с результатом.
Запишите все аргументы, оцените их важность для проекта, а затем примите решение. Когда не можешь, подбрось монетку. Ваш проект, вероятно, может быть успешно завершен с использованием любой технологии, и тратить драгоценное время на ненужные дебаты просто обойдется ненужными деньгами.
источник
Предполагая, что обе стороны на 100% верны во всех своих аргументах, какие из них имеют значение?
Вы заботитесь? Вы планируете делать то, что требует POCO?
Опять же, это то, что вы собираетесь использовать и нужно строить, если у вас его нет, потому что вы выбрали другой путь?
В основном добраться до сути которого:
Любой выдвинутый аргумент, который не идет по пути того, что вам нужно сделать, не имеет значения и не должен принимать во внимание ваше решение, поскольку есть некоторая возможность для маневра в будущем расширении.
источник
Положите мои два цента.
Как менеджер, вы должны попросить своих товарищей по команде учитывать принцип Ягни . Это поможет сократить список причин, выдвинутых обеими командами.
Вместо того, чтобы погружаться в распределенную транзакцию, вы должны рассмотреть возможность работы с компенсацией .
Последнее, что нужно учитывать, это кривая обучения. В зависимости от срока вашего проекта, будучи менеджером, вы сможете решить, нормально ли начинать изучение новой технологии или нет.
Если у вас есть достаточно времени, чтобы потратить впустую, то проведите какой-нибудь День инноваций, когда у команд A и B будет день, чтобы представить доказательства концепций, основанных на тех же требованиях.
Кстати, парню, который говорит, что « модели WCF не являются POCO, из-за [DataContract] & [DataMember] и этих атрибутов », скажите ему, что POCO обычно предназначены для доменных сущностей, и что это не лучший способ выставлять Ваш домен является объектом для любых клиентов, для этого нужны DTO.
источник
Во-первых, держите подальше субъективность. В аргументах вашей команды WebAPI я нахожу «Web API - это просто современный способ» *, «модели WCF не являются POCO из-за этих атрибутов», а «SOAP не так удобен для чтения и удобен, как JSON», довольно самоуверенный, если не совсем неправильный и не поможет принять решение.
Итак, что делать: решите, что вы хотите делать с вашими услугами , а затем выберите метод, который соответствует этой цели, ее удобству обслуживания и расширяемости с наименьшим количеством боли. Вы можете сделать это, просто исследуя, поддерживается ли какой-либо данный аспект платформой для использования.
Интересные материалы для чтения:
*: обратите внимание, что для этого вы обращаетесь к Википедии, где цитируется следующее: « Веб-приложения Web 2.0 отошли от сервис-ориентированной архитектуры (SOA) с веб-сервисами на основе SOAP в направлении более сплоченных коллекций веб-ресурсов RESTful» . Это пример использования, когда ваш сервис должен использоваться с веб-страницы. Это также легко можно сделать с помощью WCF, используя WebHttpBinding. Там не написано "Используйте WebAPI для этого" .
Если этот вопрос выходит за рамки «как управлять обсуждением» : я бы использовал WCF, если сервисы будут использоваться не-веб-клиентами, потому что его метаданные позволяют удивительно легко генерировать строго типизированные клиенты.
источник
Помимо управления командой, вы не выбираете одно над другим. Вам нужно посмотреть на назначение каждого веб-сервиса и использовать соответствующую технологию для конкретной части приложения. Это похоже на запрет процедур магазина, когда команда использует структуру сущностей.
Затем вы пишете эти 5 ~ 10% веб-сервисов в WCF. Если на сервис нужно ссылаться изнутри в других проектах, споров нет. Преимущество возможности импорта контракта WCF для создания клиентского прокси НЕ открыто для обсуждения. Требуется полная интеграция, эффективность и безопасность типов на совершенно новый уровень.
Вы пишете, что будет использоваться для публичных запросов API (возможно) / Ajax в веб-интерфейсе Asp.net.
Если это просто вызов страницы ajax, вы можете просто использовать Asp.Net MVC.
Не выбирай, обними их всех. WCF и веб-API Asp.net служат различным целям. Никто не говорит, что вы не можете иметь яблоко и апельсин в своем фруктовом салате. Попытка выбрать один над другим и столкнуть его с каждым сценарием - просто лень.
источник
Наша команда провела похожее обсуждение пару месяцев назад. Решающим фактором для нас стало то, как мы будем создавать и внедрять каждую технологию. Поскольку мы уже создавали приложение MVC и использовали Knockout.js для привязки данных, мы эффективно использовали MVVM, а контроллеры были просто API-интерфейсом для данных.
Это позволило нам классифицировать использование технологий в этом проекте следующим образом:
Хотя это может быть не очень популярный или гипертехнический ответ, сначала определите, что вам нужно, и как, или если технология поможет, моя команда решила, какую технологию использовать и где.
источник
Это был бы самый разумный подход. Довольно часто службы WCF и WebApi размещаются в одном и том же веб-приложении, где оба служат различным целям.
Просто чтобы исправить несколько аргументов:
Во многих случаях модели WCF работают без атрибутов datacontract / datamember.
Это не так, но веб-сервисы WCF обычно несут простой XML, а не раздутый SOAP. Это , безусловно , является читаемым.
Один аргумент в пользу WCF: если доступен WSDL, во многих технологиях есть тонны инструментов, которые могут создавать прокси из метаданных. С другой стороны, схема JSON еще не все широко поддерживается.
источник
Почему бы не пойти по пути с WCF Data Services? хорошие запросы в стиле OData / webapi и удобство использования с возможностями WCF, а также возможность возврата
JSONпросто отлично. Кроме того, Wcf не так уж плох, если у вас есть хороший автоматический код хостинга wcf, как показано ниже:https://github.com/ImaginaryDevelopment/MvcOdata
Я бы сказал, что они совсем не далеки друг от друга, за исключением того, что, когда мы перешли к использованию
WebApiна переднем конце иWCF data servicesна среднем уровне, мыWebApiстолкнулись с простыми вещами, такими как строка содержит операторы строки данных, соответствующие строке.источник
Хороший архитектор откладывает технологические решения до тех пор, пока они не станут абсолютно необходимыми.
Другими словами, не принимайте решение, пока клиенту не понадобится подключиться. Вы можете создать полностью протестированный сервисный уровень без фактического наложения на него механизма транспорта / связи. 95% + работы можно выполнить «под» адаптером вне рамок.
Пришло время представить эти сервисы удаленным клиентам, вы можете выбрать самые современные фреймворки и написать тонкие обертки поверх универсального сервисного уровня.
Черт возьми, если ваш «настоящий» уровень обслуживания выполнен хорошо, вы даже можете попробовать несколько оболочек с минимальными затратами.
Во всяком случае, это догматический ответ. На практике вам может потребоваться выбрать самый простой инструмент с полки для облегчения ранних и частых интеграционных тестов, но все же ограничьте свою зависимость от него и относитесь к нему строго как к просто тонкому коммуникационному слою по сравнению с реальными услугами.
Если вы воспользуетесь этим подходом, вы, вероятно, обнаружите, что вы выбрали самый простой инструмент для использования на начальном этапе, и никто не будет суетиться , потому что команда знает, что может внедрить более сложный или модный инструмент или структуру позже, при необходимости , с минимальными усилиями.
источник
Поэтому сейчас я стою перед тем же выбором, и я спросил себя, какой набор функций из WCF использует наша команда в данный момент. Используем ли мы разные протоколы? Используем ли мы поддержку транзакций? Нет (хотя мы используем нестандартные механизмы согласованности). Мы используем дуплекс? Нет .
Почему мы хотели бы использовать веб-API? Более простая интеграция с внешним интерфейсом (удаляет существующий дополнительный уровень обслуживания), SignalR для отправки ответа клиентам, кэширование для GET.
Может быть, можно найти и другие причины :) А также причины остаться с WCF.
источник
Если бы я был на вашем месте, я бы начал с изучения способностей ваших команд. Если все в вашей команде уже знают WCF, и лишь небольшой процент знает Web API, то ваше решение уже принято за вас.
В любом случае, если у вас есть время, потратьте его на изучение и совершенствование базы знаний, но не за счет потребностей бизнеса и производительности компании.
источник
Я бы спросил, какую модель взаимодействия вам нужно поддерживать? Ваш внешний интерфейс больше напоминает RPC или REST? По моему опыту это обычно где-то между, но в основном одно или другое.
Вы используете свои собственные услуги для других проектов в .Net? Это, пожалуй, самый показательный вопрос, который вы можете задать. WCF имеет то преимущество, что может абстрагировать ваши интерфейсы в отдельную библиотеку классов и иметь возможность создавать и внедрять ваш клиент. В качестве дополнения к этому, вы можете смонтировать ваш проект на основе WCF как с конечными точками JSON, так и с SOAP / WSDL, я это сделал. WCF также предлагает лучшие гарантии против определенных вами интерфейсов.
Тем не менее, если вы ожидаете иметь клиентов с других платформ XML в целом, не говоря уже о том, что SOAP имеет измеримые издержки, превышающие возможности простых конечных точек JSON. Если вы пойдете по пути JSON / Web API, вам нужно будет намного лучше документировать, как взаимодействовать с вашими конечными точками и API.
В общем, я бы предложил написать простой документ API, в котором указано, как вы будете отправлять данные и как вы хотите получить ответ для структуры объекта с одним запросом. Напишите свой тестовый пример наиболее универсальным способом и запишите его как таковой. Я бы порекомендовал простое заявление curl. Затем попросите нескольких ваших участников реализовать это с помощью WCF и с помощью веб-API. Тогда посмотри, кто победит.
Лично, несмотря на то, что я выполнил несколько относительно крупных проектов и реализаций с WCF, я фактически склоняюсь к самой простой реализации, которая, на мой взгляд, на самом деле является прямой WCF с использованием результатов JSON и некоторым поведением переопределения в Global.asax.cs для работы с ошибочными условиями. Если документация API включает в себя операторы curl, и вы можете использовать все функциональные возможности своего API с примерами curl, клиенту будет намного проще реализоваться на любом языке, который поддерживает веб-интерфейсы. Это действительно, где WCF начинает падать. Наличие четко определенного API с независимой документацией лучше, чем наличие структур с автоматизированным инструментарием при работе с сторонними системами. Выступая в качестве потребителя этих систем с других платформ.
Помимо этого, реализуйте свой клиент на двух разных языках. Сделайте клиента в C #, но также сделайте один в Node.js или Python и посмотрите, насколько хорошо они подходят. Одно это упражнение поможет вам избавиться от слабых сторон в вашем API.
источник