1

作成する必要があるサービスに servicestack を利用したいのですが、それがどのように機能するか、より正確には、自分の意図と目的のためにどのように機能させることができるかについて頭を悩ませています。私は強力な ASP のバックグラウンド、主にバックエンドを持っていないので、おそらくそれがメンタル ブロックの理由です。

ネイティブの C++ API 経由で接続するレガシー プラットフォームがあります。cli のネイティブ API を .net クラス ライブラリとしてワープしました。これは、サンプルに注入された Todo リポジトリに相当します。

前後に移動するデータは、クラス lib で値構造体として公開されます。たとえば、アカウントは次のように定義されます。

struct Account{
  int id;
  string name;
  string password;
  ...
}

注文は次のようになります。

struct Order{
  int orderId;
  int account;
  string comment;
  ...
}

ライブラリは、上記と同様に定義されたあらゆる種類の異なるオブジェクトの多くの機能と操作を公開します。私が理解しようとしているのはこれです:

1) API をコンテナーに登録するにはどうすればよいですか? より正確には、Register メソッドがどの型を取得する必要があるかをどのように認識しているかがわかりません。todo サンプルでは、​​すべてが同じアセンブリで定義されているため、バックエンドがどのように挿入されるかを確認するのは困難です。

2) フレームワークでバックエンドのライフサイクルを管理する方法はありますか? すべての接続でシングルトンにすることはできますか?

3) フィールドをリクエストにマップするクラスで構造体をラップする必要がありますか? リクエスト オブジェクトがどのように定義されているかは明確ではありませんが、リクエストの内容は、操作のためにフィールド名/タイプの URL に変換されるフィールドである必要があるようです。ラップする必要がない方法がある場合、API で公開するフィールドと公開しないフィールドを制限するにはどうすればよいですか。

4)データ型ごとにサービスを作成する必要があるので、上記の構造では、注文用に 1 つのサービスを実装し、アカウント用に 1 つのサービスを実装する必要があります。それらを 1 つに結合する方法はありますか。ss を変換して mq で話すことができるのが気に入っています。結合されたサービスを作成すると、将来的に mq で操作することが難しくなります。このアプローチの短所は何ですか。

5) 最後に、API で操作を公開したいと思います。次のようなものです。それより古いアカウントをアーカイブします....これは、成功/失敗ステータスを更新/削除なしで返す操作になります。基本的に、http リクエストを介して一部の機能を駆動します。これは ss で可能ですか? もしそうなら、この方法でそれを使用すると、フレームワークの操作に衰弱する結果が生じますか...

4

1 に答える 1

2

1) API を登録するには、組み込みの IoC と Funq を使用する必要があります。

container.Register(c => new LegacyApiService())
       .ReusedWithin(ReuseScope.Container); 

Funq は、これらのサービスを API サービスに自動的に接続できます。https://github.com/ServiceStack/ServiceStack/wiki/The-IoC-containerをご覧ください。

TryResolve メソッドを使用して、コンテナーが利用可能な場所ならどこでも解決できます。

2) 登録時に ReuseScopes を指定することで、Funq でオブジェクトの有効期間を制御できます。あなたは見たいと思うでしょう

ReuseScope.Container: Singleton scope 
// a instance is used per application lifetime

3) 構造体のプランの古いクラス (DTO) を作成する必要があります。これは ServiceStack に必要です。すべての DTO パブリック プロパティがシリアル化されます。オプションで、DataMemberAttribute と IgnoreDataMemberAttribute を使用して、シリアル化されるパブリック プロパティを制御することもできます。

4) リクエスト DTO ごとに sservice が必要です。ただし、このコードを最小限に抑えて、集中型のビジネス レイヤーを呼び出すことができます。各ルート + 動詞には個別の操作が必要であり、DTO ごとに 1 つのサービス クラスが必要になるため、これが必要です。

5) より多くのルートを簡単に定義でき、REST ルールへの準拠を強制するものは何もありません。必要に応じて HTTP 動詞を自由に実装できます。アーカイブなどのアクションを実行する特殊なルートを GET で簡単に作成できます。ここでは衰弱させる結果はありません。API コンシューマを混乱させる可能性があります。API がドキュメンテーションでどのように機能するかを全員が明確に理解できるようにしてください。

于 2013-01-17T14:25:29.870 に答える