私たちのチームでは、(分離された DB DTO を超えて) ビジネス ロジック アセンブリの階層を通じて、要求と応答の DTO を使用します。
ビジネス ロジック レイヤーで SS に依存しないという要件があります。
したがって、IReturn または IReturnVoid インターフェイスは使用しません。継承のない単純な c# オブジェクトのみを使用します。
ルーティングに関しては、AppHost.Configure でFluent APIを使用して、基本的にルーティング テーブルを作成します。
私たちの場合、ServiceStack は非常にうまく動作します。
私たちの Service.Model は、依存関係なしに、ビジネス ロジック レイヤーから使用できます。
サービス関数は実際にはシン ラッパーであり、ビジネス ロジック関数を呼び出して、応答 DTO を返します。
ただし、JsonServiceClient.Get 関数は、IReturn オブジェクトをパラメーターとしてのみ、または直接 URI を受け入れます。
Post 関数のように、 object を parameter として受け入れません。
何かアドバイス ？
更新 1。
神話,
IReturn については、残念ながら私たちの場合、ビジネス ロジック モジュールで使用しない要件があり、
より軽い SS 依存性でさえ。
サービス関数は、ビジネス モジュールを呼び出すシン ラッパーです。
2 つのレイヤー間のリンクは、要求と応答の DTO のみです。私たちはこのアプローチをとても気に入っています。
はい、それらは「メッセージ操作」ですが、アプリケーション層の間でもメッセージとして機能します。
また、私のクライアントは主に C# ではなく Jquery Ajax です。モバイルのおかげで、大多数が Jquery Ajax に傾倒しました。
したがって、この場合、IReturn でマークされていないオブジェクトのみを使用できます。ServiceStack の動作は非常に良好です。