ฉันจะปิดบริการได้อย่างไรจึงง่ายขึ้น

เรามีการพึ่งพาบริการของบุคคลที่สามซึ่งแสดงถึงอินเทอร์เฟซขนาดมหึมาซึ่งเราต้องการเพียง 3 วิธีเท่านั้น นอกจากนี้อินเทอร์เฟซเปลี่ยนบ่อย ...

ฉันตัดสินใจที่จะรวมส่วนต่อประสานในชั้นเรียนในโครงการของเราและเปิดเผยวิธีการที่เราต้องการเท่านั้น

แต่ผมไม่แน่ใจว่าผมควรจะจัดการกับค่าส่งกลับ ... Storageอินเตอร์เฟซที่ส่งกลับวัตถุของการพิมพ์ เราภายในมีชนิดซึ่งเป็นตัวแทนของเราภายในของStorageModelStorage

สิ่งที่คุณจะกลับมาใน mapper นี้StorageหรือStorageModel? เรามี DataService StorageServiceซึ่งได้รับการพึ่งพาของ wrapper injected

ขณะนี้ฉันกำลังทำมันโดยทั่วไปดังนี้:

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

คุณจะพูดอะไร:

• มันดีเหมือนข้างบนหรือเปล่าที่ wrapper คืนค่าStorageอ็อบเจกต์ภายนอกและ Internal StorageServiceคืนค่า Internal StorageModel?
• หรือคุณจะส่งคืนเครื่องStorageModelห่อหุ้มแล้ว?

ใน optinion ของฉัน wrapper ควรจัดการกับทุกสิ่งที่เกี่ยวข้องกับไลบรารีภายนอก ซึ่งหมายความว่าส่วนต่อประสานสาธารณะของ Wrapper ต้องไม่ตั้งชื่อประเภทภายนอกใด ๆ

การแม็พชนิดภายนอกกับแอปพลิเคชันของคุณนั้นเป็นส่วนหนึ่งของหน้าที่ของผู้ห่อหุ้ม หากนี่เป็นการดำเนินการที่ไม่สำคัญคุณอาจใช้เครื่องมือต่าง ๆ ที่มีอยู่ในการย่อยสลายปัญหาเช่นการฉีดวัตถุนักแปล อย่างไรก็ตามนักแปลจะต้องเป็นส่วนหนึ่งของโมดูลแรปเปอร์ของคุณและไม่มีส่วนอื่นของแอปพลิเคชันของคุณที่อาจขึ้นอยู่กับมัน

วิธีนี้ส่วนที่เหลือของแอปพลิเคชั่นของคุณไม่เพียง แต่มีผลต่อการเปลี่ยนแปลงในห้องสมุดเท่านั้น แต่ยังรวมถึงการเปลี่ยนไลบรารี่ให้เป็นอีกอันหนึ่ง

ฉันตัดสินใจที่จะรวมส่วนต่อประสานในชั้นเรียนในโครงการของเราและเปิดเผยวิธีการที่เราต้องการเท่านั้น

ไม่เป็นไร. นอกจากนี้ยังเป็นที่รู้จักกันอะแดปเตอร์

คุณเลือกรูปแบบของการ์ดเชื่อมต่อดังนั้นจุดประสงค์ในที่นี้คือเปลี่ยนอินเทอร์เฟซหนึ่ง(โมเดลไลบรารี) ไปเป็นอีกแบบหนึ่ง (โมเดลโดเมน) ดังนั้นหากบางอย่างจากรุ่นเก่ามาถึงโมเดลโดเมนอะแดปเตอร์จะไม่สามารถใช้งานได้

StorageModelตามข้อโต้แย้งก่อนหน้านี้อะแดปเตอร์ควรกลับ

ในท้ายที่สุดโดเมนของคุณ "พูด" ภาษาเฉพาะที่Storageเป็นคนแปลกหน้า

แต่ฉันไม่แน่ใจว่าฉันควรจัดการกับค่าตอบแทนอย่างไร ...

ที่สำคัญนี่คือการรู้ว่าเหตุผลสำหรับสิ่งที่คุณจะห่อ / การปรับตัวห้องสมุด

รูปแบบของอะแดปเตอร์มัณฑนากรซุ้มอาจมีความคล้ายคลึงกัน แต่มีความแตกต่างกันพอสมควร แตกต่างกันไปตามปัญหาที่พวกเขาแก้ไข

ที่กล่าวว่าคุณอาจสนใจ:

• ลวดลายด้านหน้า (ซ่อนความซับซ้อน)

• มัณฑนากรรูปแบบ (การเพิ่มประสิทธิภาพของอินเตอร์เฟซ) ควรใช้เมื่อไร

• ความแตกต่างระหว่างรูปแบบ Adapter และแบบหนังสือมอบฉันทะ

• เลเยอร์ต่อต้านการทุจริตคืออะไรและมีการใช้งานอย่างไร (ซ่อนคุณภาพต่ำและรหัสยุ่ง)

คุณไม่สามารถล้อมไลบรารีได้อย่างมีประสิทธิภาพด้วยการทำซ้ำ

สิ่งที่คุณควรห่อคือการใช้งานไลบรารี่ของคุณและนั่นหมายความว่าจะไม่เปิดเผยวัตถุในกรณีนี้ที่เก็บข้อมูล อย่าพยายามทำสำเนาซ้ำ

ใช้ห้องสมุด แต่เก็บไว้ในนั้น ดังนั้นในกรณีของคุณสมมติว่าคุณใช้ StorageService เพื่อจัดเก็บสิ่งต่าง ๆ ที่คุณควรห่อไว้ในที่เก็บ

MyPocoObjectRepo
    MyPocoObject GetObject(string id);

ที่ MyPocoObject เป็นข้อมูลและตรรกะทางธุรกิจของคุณทั้งหมด ไม่ใช่การซ้ำซ้อนของ Storage หรือ DataReader หรืออะไรก็ตาม

คำตอบก็คือว่ามันขึ้นอยู่กับว่าหรือไม่คุณจำเป็นต้องเข้าถึงได้โดยตรงจากระดับที่ไม่ได้เป็นStorageStorageModel

หากคุณกำลังจะล้อมไลบรารีมันก็ควรห่อหุ้มวัตถุที่ถูกส่งคืนโดยมันเพื่อให้คุณสามารถพิสูจน์การเปลี่ยนแปลงในอนาคตของไลบรารีในอนาคต อย่างไรก็ตามหากคุณจำเป็นต้องใช้Storageโดยตรงหมายความว่าอาจจำเป็นต้องส่งคืนสินค้าStorageตามสถานการณ์ อาจมีการโต้แย้งว่าการให้สิทธิ์Storageการใช้งานที่นี่เป็นไปStorageModelตามที่คุณต้องการจะคงที่ตลอดโปรแกรมของคุณ

ฉันขอแนะนำให้คุณห่อทั้งอินเทอร์เฟซและวัตถุที่ส่งคืนถ้าคุณยังไม่ได้ทำเช่นนั้นแม้ว่ามันจะเหมาะสมถ้าคุณใช้ในStorageModelโปรแกรมของคุณStorageเท่านั้น