3

私は (Windows) システム管理者のバックグラウンドを持つ C# コーダーです。さまざまなインフラストラクチャ コンポーネント (Windows 管理、ハードウェア管理など) 用の統合 REST-API を作成するために、さまざまなサービス フレームワークを検討してきました。このためのフレームワークとして ServiceStack を使用することにしましたが、DTO の管理方法について質問があります。ほとんどの場合、ソース データは、次のようなデータベース以外のオブジェクトから取得されます。

  • その他の Web サービス (通常は SOAP ベース)。私は通常、「Web 参照の追加」を介してこれらを取り込みます (すべてではありませんが、ほとんどが asmx です)。
  • .NET オブジェクト (通常は WMI/WinRM/PowerShell [System.Management]、または Active Directory [System.DirectoryServices])...
  • いくつかの不幸なケースでは、(ssh または cmd を介して) コマンドを呼び出した結果、生のテキスト出力が得られます。

これらのすべてのケースで、何らかの Save() メソッドを呼び出してプロパティを更新する必要があります。さらに、REST サービスに公開したい CRUD 以外のメソッドがいくつかあるかもしれません。通常、ソース データのすべてを必要とするわけではありません (たとえば、Web サービス データの場合、特定のプロキシ クラスの特定のプロパティとメソッドをボックス化することにのみ関心があります)。私の理解では、私の DTO はクリーンで、依存関係がないようにする必要があります。使用できる ORM があるとは思えないので、データを DTO にマップするにはどの設計パターンを使用すればよいですか?

ここで用語を誤用していたら申し訳ありません...

4

2 に答える 2

2

さまざまなバックエンド サービスとデータ ソースがあるため、フレームワークのような高度に構造化されたものを使用してデータを DTO にマッピングするのは難しいと思います。私はそれを簡単に保ちます：

DTO クラスをバックエンド クラスから分離してください。通常、DTO でコードを再利用したり、継承を使用したりしようとする誘惑に抵抗してください (ただし、DTO が実装するインターフェイスを宣言すると便利な場合もあります)。これにより、ServiceStack サービスのインターフェースがクリーンに保たれ、バックエンドの詳細に依存しなくなります。

TranslateToServiceStack には、PopulateWith、 、 などの2 つのクラス間でプロパティを簡単にマップするための拡張メソッドがいくつかありますPopulateWithNonDefaultValues。上記のリンクはこれらについて言及しています。DTO クラスをバックエンド クラスのサブクラスにしたり、バックエンド クラスを直接再利用したりしてはいけませんが、これらのマッピング メソッドを使用する場合は、プロパティ名を一致させると便利です。

ServiceStack サービス クラスをシンプルに保ちます。彼らの主な責任は、DTO クラスと下位レベルのモデル クラスとの間の変換と、実際の作業を行うためにビジネス ロジック クラスで 1 つまたは 2 つのメソッド呼び出しを行うことです。

ビジネス レイヤー (ServiceStack サービスがやり取りするクラス) の最上位レベルで、特定の種類のデータのソースと形式に関する詳細を抽象化するクリーンなインターフェイスを提供すると便利なようです。したがって、モデル クラスの 3 つの層が必要になる場合があります。上から順に、DTO、ビジネス層の POCO クラス、および Web 参照生成コードなどの特定のバックエンド サービス用のフレームワーク固有のクラスです。

大体これに尽きると思います。

于 2013-08-22T15:33:18.440 に答える