Bagaimana cara saya membungkus layanan sehingga lebih sederhana

Kami memiliki ketergantungan pada layanan pihak ketiga yang memperlihatkan antarmuka raksasa yang hanya kami butuhkan seperti 3 metode. Selain itu, antarmuka sering berubah ...

Saya telah memutuskan untuk membungkus antarmuka dalam kelas di proyek kami dan hanya memaparkan metode yang kami butuhkan.

Tapi saya tidak yakin bagaimana saya harus menangani nilai kembali ... Antarmuka mengembalikan objek bertipe Storage. Kami memiliki tipe StorageModelinternal yang merupakan representasi internal kami dari a Storage.

Apa yang akan Anda kembalikan di mapper: Storageatau StorageModel? Kami memiliki DataService StorageServiceyang mendapatkan ketergantungan bungkus yang disuntikkan.

Saat ini saya melakukannya pada dasarnya seperti ini:

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);
        }
    }
}

Apa yang akan Anda sampaikan:

• Apakah bagus seperti di atas, bahwa pembungkus mengembalikan Storageobjek eksternal dan internal StorageServicemengembalikan internal StorageModel?
• Atau apakah Anda sudah mengembalikan StorageModelpembungkusnya?

Menurut pendapat saya, pembungkus harus berurusan dengan semua hal yang berkaitan dengan perpustakaan eksternal. Ini berarti bahwa antarmuka publik Wrapper tidak boleh menyebutkan jenis eksternal apa pun.

Memetakan tipe eksternal ke masing-masing jenis aplikasi Anda adalah bagian dari tugas pembungkus. Jika ini bukan operasi sepele, maka Anda dapat menggunakan berbagai alat yang tersedia untuk menguraikan masalah, misalnya menyuntikkan objek penerjemah. Namun, penerjemah masih harus menjadi bagian dari modul pembungkus Anda, dan tidak ada bagian lain dari aplikasi Anda yang bergantung padanya.

Dengan cara ini, sisa aplikasi Anda benar-benar kebal tidak hanya terhadap perubahan di perpustakaan, tetapi juga untuk penggantian perpustakaan untuk yang lain.

Saya telah memutuskan untuk membungkus antarmuka dalam kelas di proyek kami dan hanya memaparkan metode yang kami butuhkan.

Tidak apa-apa. Ini juga dikenal sebagai Adaptor .

Anda memilih pola Adaptor , jadi tujuannya di sini adalah mengubah satu antarmuka (model perpustakaan) menjadi yang lain (model domain). Jadi, jika sesuatu dari yang pertama mencapai model domain, adaptor gagal untuk tujuannya .

Menurut argumen sebelumnya, adaptor harus mengembalikan StorageModel.

Pada akhirnya, domain Anda "berbicara" bahasa tertentu, di mana Storageadalah orang asing .

Tapi saya tidak yakin bagaimana saya harus menangani nilai pengembalian ...

Kuncinya di sini adalah mengetahui untuk alasan apa Anda membungkus / mengadaptasi perpustakaan .

Adaptor, dekorator, pola fasad mungkin memiliki kesamaan tetapi mereka cukup berbeda. Berbeda dengan masalah yang mereka pecahkan.

Karena itu, Anda mungkin juga tertarik pada:

• Pola fasad (kompleksitas persembunyian)

• Pola dekorator (peningkatan antarmuka) . Kapan menggunakannya

• Perbedaan antara pola Adaptor dan Pola Proxy .

• Apa itu lapisan anti-korupsi dan bagaimana itu digunakan (menyembunyikan kualitas rendah dan kode berantakan)

Anda tidak dapat membungkus perpustakaan secara efektif dengan menduplikasi.

Apa yang harus Anda bungkus adalah penggunaan perpustakaan dan itu berarti tidak mengeksposnya objek, dalam hal ini Storage. Jangan coba menduplikasi mereka juga.

Gunakan perpustakaan, tetapi tetap berisi. Jadi dalam kasus Anda, dengan asumsi Anda menggunakan StorageService untuk menyimpan hal-hal yang Anda harus membungkusnya dalam repositori

MyPocoObjectRepo
    MyPocoObject GetObject(string id);

di mana MyPocoObject sepenuhnya data dan logika bisnis Anda. Bukan duplikasi Penyimpanan atau DataReader atau apa pun

Jawabannya adalah itu tergantung pada apakah Anda perlu mengakses Storagelangsung dari kelas yang tidak StorageModel.

Jika Anda akan membungkus pustaka, masuk akal juga untuk membungkus objek yang dikembalikan olehnya untuk memberi Anda bukti perubahan di masa depan yang dibuat oleh pustaka di masa mendatang. Namun jika Anda perlu menggunakannya Storagesecara langsung, itu berarti mungkin perlu kembali Storagesesuai situasi. Sebuah argumen dapat dikatakan untuk mewajibkan Storagepenggunaan di sini StorageModelkarena Anda mungkin ingin tetap konsisten di seluruh program Anda.

Saya akan sangat menyarankan Anda membungkus antarmuka dan objek yang dikembalikan jika Anda belum melakukannya, sekali lagi, itu hanya masuk akal jika Anda hanya menggunakan StorageModelseluruh program Anda dan tidak Storage.