Задача
Я знаю об основном способе создания маршрута/конечной точки в ServiceStack с использованием методов с именами типа «Get», «Post», «Any» и т. Д. Внутри службы, но в конкретном случае что я пытаюсь работать с моим существующим сервисом (который я могу сделать IService через наследование), которые не могут быть модифицированы с атрибутами ServiceStack и в настоящее время используют DTO для запросов и ответов.Есть ли способ связать конкретный метод с маршрутом в ServiceStack?
Эта служба содержит множество функций, которые я не хочу маскировать вручную (так как это проходной уровень), но в ином случае уже соответствует требованиям ServiceStack. Мне интересно, если есть способ вручную создать эти маршруты таким образом, чтобы это работало, как будто я издевался над here. Мои существующие функции и DTO уже содержат информацию, которую мне нужно определить для маршрутов, поэтому, если такой подход возможен, мне потребуется только перечислить их во время инициализации, а не создавать уровень сервиса вручную.
Я заметил, что существует метод расширения на Routes.Add, который принимает выражение типа Expression>, но я не смог получить эту работу, потому что я считаю, что базовый код делает предположения о типе генерируемого выражения (LambdaExpression vs MemberExpression или что-то типа того). Я также могу лаять неправильное дерево, если это не намеченная цель этой функции, но я не могу найти документацию в любом месте о том, как этот вариант должен работать.
Почему?
Я не уверен, что это необходимо, но для того, чтобы пролить свет на то, почему я хочу сделать это, в отличие от переоснащения существующих слоев: текущий код также используется вне контекста веб-службы и потребляется другим кодом внутренне. Повторная настройка ServiceStack на этот уровень сделает каждое место, которое его потребляет, потребует сборки ServiceStack и будет знать о веб-сервисе, который является проблемой, которую я хочу отделить от нижнего кода. Ранее мы использовали MVC/WCF для достижения этой цели, но нам нужны некоторые функции, доступные из ServiceStack.
текущая архитектура выглядит следующим образом: данные -> DAL -> дискретного бизнеса-логика -> состав -> Веб-сервис
Надеется, что делает достаточно здравого смысла, и я не быть тупым. Если вы хотите получить более подробную информацию о том, что я хочу сделать, или почему я попытаюсь как можно скорее обновить этот пост.
Спасибо!
Вы можете предлагать запросы функций на [голос пользователя ServiceStack] (http://servicestack.uservoice.com/forums/176786-feature-requests), но необязательная делегирование вроде этого не является чем-то, что мы видим. Значение ServiceStack сервисный уровень должен быть самым внешним слоем, который реализует контракт с внешним сервисом, это просто создает ненужную путаницу, которая не добавляет большого значения по сравнению с явной, интуитивно понятной и отлаживаемой альтернативой, которая в настоящее время существует. – mythz
Спасибо за ваш ответ. Хотя я понимаю вашу позицию, я все еще заинтересован в ее преследовании.Если вы не возражаете, мне интересно, где в коде посмотреть, где происходит эта делегация (и, возможно, расширять ее). Кроме того, если вы знаете какую-либо документацию об этом параметре Expression, мне бы очень хотелось это увидеть. Еще раз спасибо за ответ. –
Существует некоторая часть подготовительной работы, которая происходит до подготовки кешей, но вы можете поместить здесь [точку прерывания] (https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/Host/ ServiceExec.cs # L168), где вызывается глагол. – mythz