Làm thế nào để tôi bọc một dịch vụ để nó đơn giản hơn

Chúng tôi có một sự phụ thuộc vào dịch vụ của bên thứ ba, cho thấy một giao diện khổng lồ mà chúng tôi chỉ cần như 3 phương thức. Ngoài ra, giao diện thay đổi thường xuyên ...

Tôi đã quyết định bọc giao diện trong một lớp trong dự án của chúng tôi và chỉ đưa ra các phương thức mà chúng tôi cần.

Nhưng tôi không chắc mình nên xử lý các giá trị trả về như thế nào ... Giao diện trả về một đối tượng kiểu Storage. Chúng tôi trong nội bộ có một loại StorageModelđó là đại diện nội bộ của chúng tôi về a Storage.

Những gì bạn sẽ trở lại trong mapper: Storagehoặc StorageModel? Chúng tôi có một Dịch vụ dữ StorageServiceliệu nhận được sự phụ thuộc của trình bao bọc được chèn.

Hiện tại tôi đang làm về cơ bản như thế này:

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

Bạn muốn nói gì:

• Có tốt như trên không, rằng trình bao trả về Storageđối tượng bên ngoài và bên trong StorageServicetrả về nội bộ StorageModel?
• Hoặc bạn sẽ trả lại một StorageModeltrong bọc?

Theo lựa chọn của tôi, trình bao bọc sẽ xử lý tất cả những thứ liên quan đến thư viện bên ngoài. Điều này có nghĩa là giao diện chung của Wrapper không được đặt tên cho bất kỳ loại bên ngoài nào.

Ánh xạ các loại bên ngoài vào các loại ứng dụng tương ứng của bạn là một phần của nhiệm vụ của trình bao bọc. Nếu đây không phải là một hoạt động tầm thường, thì bạn có thể sử dụng các công cụ khác nhau có sẵn để phân tích vấn đề, ví dụ như tiêm một đối tượng dịch. Tuy nhiên, trình dịch vẫn phải là một phần của mô-đun trình bao bọc của bạn và không có phần nào khác trong ứng dụng của bạn có thể phụ thuộc vào nó.

Bằng cách này, phần còn lại của ứng dụng của bạn hoàn toàn miễn dịch không chỉ với những thay đổi trong thư viện mà còn thay thế thư viện cho một thư viện khác.

Tôi đã quyết định bọc giao diện trong một lớp trong dự án của chúng tôi và chỉ đưa ra các phương thức mà chúng tôi cần.

Vậy là được rồi. Điều này còn được gọi là Adaptor .

Bạn chọn mẫu Bộ điều hợp , vì vậy mục tiêu ở đây là chuyển đổi một giao diện (mô hình thư viện) sang một giao diện khác (mô hình miền). Vì vậy, nếu một cái gì đó từ trước đây đạt đến mô hình miền, bộ điều hợp không đạt được mục đích của nó .

Theo các đối số trước đó, bộ điều hợp nên trả về StorageModel.

Cuối cùng, tên miền của bạn "nói" một ngôn ngữ cụ thể, nơi Storagelà một người lạ .

Nhưng tôi không chắc mình nên xử lý các giá trị trả về như thế nào ...

Chìa khóa ở đây là để biết lý do bạn đang gói / điều chỉnh thư viện .

Các mẫu Adaptor, Decorator, Facade có thể có những điểm tương đồng nhưng chúng khá khác nhau. Khác nhau như những vấn đề họ giải quyết.

Điều đó nói rằng, bạn cũng có thể quan tâm:

• Mô hình mặt tiền (ẩn phức tạp)

• Mẫu trang trí (tăng cường giao diện) . Khi nào sử dụng nó

• Sự khác nhau giữa mẫu Adaptor và Mẫu Proxy .

• Lớp chống tham nhũng là gì và cách sử dụng (ẩn mã chất lượng thấp và lộn xộn)

Bạn không thể bao bọc một thư viện một cách hiệu quả bằng cách sao chép nó.

Những gì bạn nên bọc là bạn sử dụng thư viện và điều đó có nghĩa là không để lộ đối tượng, trong trường hợp này là Storage. Đừng cố gắng sao chép chúng.

Sử dụng thư viện, nhưng giữ nó chứa. Vì vậy, trong trường hợp của bạn, giả sử bạn sử dụng StorageService để lưu trữ những thứ bạn nên gói nó trong kho

MyPocoObjectRepo
    MyPocoObject GetObject(string id);

trong đó MyPocoObject hoàn toàn là dữ liệu và logic kinh doanh của bạn. Không phải là một bản sao của Storage hoặc DataReader hoặc bất cứ thứ gì

Câu trả lời là nó phụ thuộc vào việc bạn có cần truy cập Storagetrực tiếp từ một lớp không StorageModel.

Nếu bạn định bọc thư viện, thì cũng nên bọc đối tượng mà nó trả lại để cho bạn những thay đổi bằng chứng trong tương lai được thực hiện bởi thư viện trong tương lai. Tuy nhiên nếu bạn cần sử dụng Storagetrực tiếp, điều đó có nghĩa là có thể cần phải quay lại Storagetheo tình huống. Một đối số có thể được nói cho việc bắt buộc Storagesử dụng ở đây là StorageModelnhư bạn có thể muốn duy trì sự nhất quán trong suốt chương trình của bạn.

Tôi thực sự khuyên bạn nên bọc cả giao diện và đối tượng được trả lại nếu bạn chưa làm như vậy, điều đó chỉ có ý nghĩa nếu bạn chỉ sử dụng StorageModeltrong suốt chương trình của mình chứ không phải Storage.