2

既存のwcfrestapiをServiceStackに変換しようとしていますが、すぐに問題が発生します。

[Route("foo/{userId}","POST")]
public class MyInputModel : IReturnVoid
{
    public string userId { get; set; }
    public SomeOtherObject properties { get; set; }
}

ここでの目的は、URLにuserIdを指定し、投稿本文にSomeOtherObjectのインスタンスを指定することです。私が得るエラーは

<Message>Could not deserialize 'application/xml' request using MyInputModel'
Error: System.Runtime.Serialization.SerializationException: 
Error in line 1 position 42. Expecting element 'MyInputModel' 
from namespace 'blahblahblah'.. Encountered 'Element'  with name 
'SomeOtherObject', namespace 'http://blahblahblah'.

私が考えることができる唯一のことは、シリアライザーをMyInputModel幸せにするためにxmlをaでラップすることです。これは、実際には下位互換性のためのオプションではありません。

SomeOtherObjectトップレベルの入力モデルになるように変更してUserId、そこにプロパティを配置することもできますが、これはAPI全体で使用されるオブジェクトであり、実際にはユーザーIDに関連付けられていないため、最適ではないと感じます。また、すでに独立して公開されているため、そこで変更を加えるのは面倒です。

投稿されたデータのルート要素が挿入されることを示す方法はありますSomeOtherObjectかMyInputModel？WebApiでは、これは[FromBody]属性などを使用します。servicestackに似たようなものはありますか？

4

1 に答える 1

4

DTOの目的は、ワイヤー形式を自動生成することです。そのため、ServiceStackでは、要求DTOが着信要求の形状と一致する必要があります。ServiceStackを非常に生産的にしている理由の一部は、 C＃から開始して投影することを奨励するコードファーストWebサービスフレームワークです。つまり、クライアントはWebサービス出力にバインドする必要があり、コードファーストモデルを既存のモデルにマッピングする逆ではありません。スキーマ入力。

そうは言っても、Serialization / Deserialization wikiページには、ServiceStackのデフォルトのリクエストバインディングを独自のものでオーバーライドするさまざまな方法がリストされています。

任意のサービスまたはフィルターでHTTPリクエスト変数にアクセスする

すべてのHTTP変数は、任意のサービスまたはフィルターから利用可能なIHttpRequestから引き続きアクセスできるため、すべてをDTOにマップする必要はありません。

base.Request.QueryString
base.Request.FormData
base.Request.Headers[name]
base.Request.PathInfo
base.Request.AbsoluteUri
于 2013-02-20T19:23:16.990 に答える