タグ付けされた質問 「wrapper」

2012年 のこの質問の著者と2013 年のこの質問の著者のように、アプリケーションを適切にテストするためにラップする必要があるサードパーティのライブラリがあります。一番上の答えの状態： 常にインターフェイスの背後にサードパーティのタイプとメソッドをラップする必要があります。これは退屈で痛みを伴う場合があります。コードジェネレータを記述したり、ツールを使用してこれを行うことができます。 私の場合、ライブラリはオブジェクトモデル用であり、その結果、この戦略を成功させるためにラップする必要があるクラスとメソッドの数が多くなります。単に「退屈で痛みを伴う」だけでなく、これはテストの難しい障壁になります。 この質問から4年間で、分離フレームワークが大きく進歩したことを認識しています。私の質問は、サードパーティのライブラリを完全にラップする効果を達成するためのより簡単な方法が今あるのでしょうか？このプロセスの痛みを取り除き、手作業の労力を減らすにはどうすればよいですか？ 私の質問はラッピングの手間を減らすことに関するものなので、私の質問は最初にリンクした質問の複製ではありません。これらの他の質問は、ラッピングが理にかなっているかどうかを尋ねるだけであり、どのように労力を小さく保つことができるかではありません。

16 unit-testing  third-party-libraries  wrapper 

私たちは、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); } …

11 c#  design-patterns  programming-practices  code-reviews  wrapper