サービスをラップして簡単にする方法

私たちは、3つのメソッドのように必要なだけの巨大なインターフェースを公開するサードパーティのサービスに依存しています。さらに、インターフェースは頻繁に変更されます...

プロジェクトのクラスにインターフェイスをラップし、必要なメソッドのみを公開することにしました。

しかし、私は戻り値をどのように処理するべきかわかりません...インターフェイスは型のオブジェクトを返しますStorage。内部StorageModelには、の内部表現であるタイプがありますStorage。

マッパーで何を返しますか：StorageまたはStorageModel？StorageService挿入されたラッパーの依存関係を取得するDataServiceがあります。

現在、私は基本的に次のようにしています：

public class StorageService 
{
    private readonly IExternalStorageWrapper externalStorageWrapper;

    public StorageService(IExternalStorageWrapper externalStorageWrapper)
    {
        this.externalStorageWrapper = externalStorageWrapper;
    }

    public StorageModel GetStorage(int storageId)
    {
        return this.externalStorageWrapper.GetStorage(storageId).ConvertToStorageModel();
    }
}

public class ExternalStorageWrapper : IExternalStorageWrapper
{
    public Storage GetStorage(int storageId)
    {
        using(var ext = new ExternalStorage())
        {
            return ext.GetStorage(storageId);
        }
    }
}

あなたは何と言うでしょう：

• 上記のように、ラッパーが外部StorageオブジェクトをStorageService返し、内部が内部オブジェクトを返すのは良いStorageModelですか？
• またはStorageModel、ラッパーですでに返しますか？

私の意見では、ラッパーは外部ライブラリに関連するすべてのものを処理する必要があります。これは、Wrapperのパブリックインターフェースが外部型を指定してはならないことを意味します。

外部型をアプリケーションのそれぞれの型にマッピングすることは、ラッパーの役割の一部です。これが簡単な操作でない場合は、トランスレータオブジェクトの挿入など、さまざまなツールを使用して問題を分解できます。ただし、トランスレータは引き続きラッパーモジュールの一部である必要があり、アプリケーションの他の部分がこれに依存することはできません。

このようにして、アプリケーションの残りの部分は、ライブラリの変更だけでなく、ライブラリを別のライブラリに置き換えても完全に影響を受けません。

プロジェクトのクラスにインターフェイスをラップし、必要なメソッドのみを公開することにしました。

それで大丈夫です。これはアダプタとも呼ばれます。

アダプターパターンを選択するので、ここでの目的は、1つのインターフェイス（ライブラリモデル）を別のインターフェイス（ドメインモデル）に変換することです。したがって、前者の何かがドメインモデルに到達した場合、アダプタはその目的に失敗しています。

前の引数によれば、アダプタはを返す必要がありStorageModelます。

最終的に、あなたのドメインは、特定の言語、「話す」Storageで見知らぬ人を。

しかし、私は戻り値をどのように処理するべきかわかりません...

ここで重要なのは、ライブラリをラップ/適応している理由を知ることです。

アダプター、デコレーター、ファサードパターンには類似点があるかもしれませんが、かなり異なります。彼らが解決する問題と同じくらい異なります。

とはいえ、あなたも興味があるかもしれません：

• ファサードパターン （複雑さを隠す）

• デコレータパターン （インターフェース拡張）。いつ使うか

• アダプタパターンとプロキシパターンの違い。

• 腐敗防止レイヤーとは何ですか？その使用方法 （低品質で面倒なコードを隠す）

ライブラリを複製して効果的にラップすることはできません。

ラップする必要があるのはライブラリの使用法であり、これはオブジェクト、この場合はストレージを公開しないことを意味します。それらを複製しようとしないでください。

ライブラリを使用しますが、ライブラリは保持してください。したがって、あなたのケースでは、StorageServiceを使用して物事を保存すると仮定すると、リポジトリにラップする

MyPocoObjectRepo
    MyPocoObject GetObject(string id);

ここで、MyPocoObjectは完全にデータとビジネスロジックです。StorageやDataReaderなどの複製ではない

答えは、そうStorageでないクラスから直接アクセスする必要があるかどうかに依存するということですStorageModel。

ライブラリをラップする場合は、ライブラリによって返されたオブジェクトをラップして、今後ライブラリによって行われる将来の変更を証明できるようにすることは理にかなっています。ただし、Storage直接使用する必要がある場合はStorage、状況によっては返品が必要になる場合があります。プログラム全体で一貫性を保つ必要がある可能性が高いStorageためStorageModel、ここでの使用を義務付けることについての議論は言えるでしょう。

インターフェースと返されたオブジェクトの両方をまだラップしていない場合は、ラップすることを強くお勧めします。ただし、これは、StorageModelプログラム全体でのみ使用していて、で使用していない場合にのみ意味がありますStorage。