作成する必要があるサービスに 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 で可能ですか? もしそうなら、この方法でそれを使用すると、フレームワークの操作に衰弱する結果が生じますか...