กรอบการฉีดของการพึ่งพามีความเสี่ยงต่อการพึ่งพาหรือไม่

ฉันทำการปรับโครงสร้างระบบที่มีอยู่เพื่อใช้การฉีดแบบพึ่งพาและงานนั้นดำเนินไปอย่างราบรื่น

หลังจากนั้นไม่นานฉันก็สังเกตเห็นว่าห้องสมุดในบ้านจำนวนมากขึ้นอยู่กับกรอบ DI ที่ฉันใช้ ดังนั้นโครงการทั้งหมดในขณะนี้ขึ้นอยู่กับกรอบงานของบุคคลที่สาม

ฉันเห็นประชดในการแยกการอ้างอิงทั้งหมดโดยทำให้พวกเขาขึ้นอยู่กับห้องสมุดสาธารณะ

ปฏิกิริยาแรกของฉันคือการสร้างห้องสมุด wrapper รอบกรอบการพึ่งพา ดังนั้นฉันสามารถแทนที่เฟรมเวิร์กนี้ได้ถ้าจำเป็น หลังจากประเมินงานที่เกี่ยวข้องแล้วฉันก็ตระหนักว่า API ที่ได้นั้นจะคล้ายกับเฟรมเวิร์กที่มีอยู่และทำให้การแทนที่ยากขึ้น ดังนั้นฉันจึงละทิ้งความคิด

ความกังวลของฉันคือกรอบ DI ที่ฉันใช้ล้าสมัยหรือจำเป็นต้องเปลี่ยน

มีรูปแบบการพัฒนาเมื่อทำงานกับ DI ที่ลดการเชื่อมต่อระหว่างโครงการและกรอบ DI หรือไม่?

คุณถูกต้องสมบูรณ์ - การใช้ DI Framework จะทำให้โค้ดของคุณขึ้นอยู่กับสิ่งนั้นเป็นส่วนใหญ่ ที่จริงแล้วมันน่าประหลาดใจมากเนื่องจากนี่เป็นเรื่องจริงสำหรับทุก ๆ เฟรมเวิร์กหรือไลบรารีพื้นฐานโดยเฉพาะอย่างยิ่งเมื่อ lib นั้นสนับสนุนโครงการของคุณด้วยคุณสมบัติทั่วไปบางอย่างที่ใช้ในรหัสของคุณ ตัวอย่างเช่นเมื่อคุณตัดสินใจที่จะใช้เฟรมเวิร์ก UI หรือเว็บเฟรมเวิร์กการตัดสินใจนี้ยากที่จะเปลี่ยนแปลงหลังจากนั้นทันทีที่คุณสร้างรหัสจำนวนหนึ่งตามไลบรารีนั้น เมื่อคุณตัดสินใจที่จะใช้Stringคลาสที่เฉพาะเจาะจง (อาจไม่ได้มาตรฐาน) คุณจะไม่สามารถเปลี่ยนการตัดสินใจในภายหลังได้อย่างง่ายดาย การตัดสินใจเช่นนี้เป็นสถาปัตยกรรมมันเหมือนกับการเลือกภาษาการเขียนโปรแกรมบางอย่างและพยายามเปลี่ยนการตัดสินใจนั้นหลังจากคุณเขียนโค้ดบรรทัดมากกว่า 100K

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

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

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

• เขียนกรอบของคุณเอง

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

ความคิดในการสร้าง wrapper library ไม่ใช่เรื่องใหม่ แต่ฉันไม่ค่อยเห็นว่าการทำงานเนื่องจากคุณจะต้องตั้งสมมติฐานสำหรับสถานการณ์ในอนาคตที่คุณไม่ทราบว่าจะตีคุณหรือไม่และเมื่อใด กรอบการทำงาน "ใหม่" จะมีลักษณะดังนี้ ในทางตรงกันข้ามเมื่อหลายปีก่อนเราประสบความสำเร็จในการแลกเปลี่ยนเฟรมเวิร์ก UI ที่สมบูรณ์ในโครงการ C ++ ด้วยบรรทัดรหัส ~ 120K โดยใช้กลยุทธ์อะแดปเตอร์ที่ฉันกล่าวถึงข้างต้น

การสร้างคอนสตรัคเตอร์ธรรมดาไม่จำเป็นต้องมีกรอบเลย สิ่งเดียวที่คุณสูญเสียคือความสามารถในการรวมศูนย์การพึ่งพาของคุณไว้ในไฟล์กำหนดค่า

คอนเทนเนอร์ DI เป็นรูปแบบ "ซอฟต์แวร์องค์กร" ซึ่งใช้เมื่อกราฟวัตถุมีขนาดใหญ่และซับซ้อน ฉันสงสัยว่า 95% ของแอปพลิเคชันไม่จำเป็นต้องใช้

ฉันไม่คิดว่ากรอบ DI สามารถล้าสมัยได้ทุกเวลาเร็ว ๆ นี้ จะเกิดอะไรขึ้นเพื่อทำให้ล้าสมัย?

• การประดิษฐ์รูปแบบใหม่และชาญฉลาดอาจจะ? อย่างไรก็ตามมันควรจะดูเหมือนว่ามันจะต้องมีการเปลี่ยนแปลงที่ใหญ่กว่าในรหัส
• การเปลี่ยนแปลงในภาษาอาจจะ? ยิ่งเลวร้ายลง.

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

ฉันค่อนข้างแน่ใจว่าการเปลี่ยนเฟรมเวิร์ก DI จะเป็นลำดับความสำคัญได้ง่ายกว่าการเปลี่ยนไลบรารี่อื่น ๆ (เช่นการเปลี่ยน UI หมายถึงทำงานได้มากกว่า)