У кого-нибудь есть опыт работы с ServiceStack или другой инфраструктурой сервисов .Net?

Ответ 1

Я планирую использовать ServiceStack в своей системе, я нашел его очень крутым, очень впечатляющим в том, как он реализует некоторые шаблоны, и мне нравится архитектура

Существуют различия в том, как вы намереваетесь предоставлять услуги. Тем не менее, рамки могут быть использованы: (ясно, что это зависит от ситуаций)

• Agatha-rrsl, который реализует шаблон rrsl, он позволяет использовать службу в ServerAndClient в том же процессе или распределенной среды, например. веб-приложение, использующее внешние службы (Agatha использует WCF для внешних служб).
• OpenRasta мощная инфраструктура, которая может быть использована для создания всего приложения или просто служб REST
• NServiceBus, который реализует полную архитектуру Service Bus и может использоваться в ServerAndClient в тот же процесс или в распределенном виде, который является лучшим для этой структуры
• MassTransit, аналогичный NServiceBus (лично я предпочитаю NServiceBU)
• SimpleServiceBus, похожий на NServiceBus, но более простой, классный
• RhinoServiceBus, своего рода вилка на NServiceBus очень круто.

Очень важно понять разницу между сервисной инфраструктурой, такой как Agatha, и служебной шиной, такой как NServiceBus. Хорошим моментом может стать отличное сообщение в блоге Дэви Бриона об этом аргумент http://davybrion.com/blog/2010/01/agatha-vs-nservicebus/

Возможно, если я вспомню что-то еще, я обновлю позже Надеюсь, что это поможет.

Ответ 2

Я рад слышать, что вы рассматриваете ServiceStack: Это основа, которая разрабатывалась в течение последних нескольких лет, рожденный из-за фрустраций и трений, вызванных жесткостью существующей .NET-инфраструктуры .asmx и WCF SOAP. Я обнаружил, что ни одна из существующих фреймворков не продвинула традиционный подход, основанный на кодах, который следует за лучшими практиками Мартина Фаулера Образцы объектов передачи данных, который, как я считаю, играет важную роль в создании хорошо определенных, менее частых, кэшируемых и повторно используемых веб-сервисов.

Основные цели:

• Продвижение лучших практик Разработка С# - слабосвязанные, тестируемые (агностические/конечные точки).
• Разработка веб-сервисов Best-practices. Контракт вашего веб-сервиса - это самый важный интерфейс, который вы, вероятно, когда-либо сделаете, поэтому он должен быть в коде, сильным и четко определенным.
• Повторяемая архитектура, управляемая моделью. Обратите внимание, что ваши службы наследуются от бесплатного IService [of T], который также может быть повторно использован в службах очереди сообщений.
• Кросс-платформенный - поддерживает как Windows (.NET)/Linux/OSX (MONO)
• Производительность - время безотказной работы и использует только самые быстрые .NET-компоненты для всех своих функций.
• Cacheability - Кэширование является важной частью высокопроизводительных масштабируемых сервисов, поэтому иногда важно иметь мелкомасштабный контроль над вашим кешированием, иметь возможность кэшировать наиболее оптимальный результат (например, gzipped response) и иметь множество поставщиков кэширования. См. Пример Northwind.

Ответ 3

Взгляните на Нелибур, Преимущества

• следует за шаблоном объекта передачи данных
• крошечные и многоразовые веб-службы.
• полная мощность WCF
• бесплатно