เราจะสร้างซอฟต์แวร์ที่เสียบปลั๊กได้อย่างไร


20

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

คุณต้องคำนึงถึงอะไรรูปแบบการออกแบบสำหรับ ฯลฯ นี้คืออะไร


รูปแบบเช่นผู้สังเกตการณ์, ผู้ไกล่เกลี่ย, คำสั่งห่วงโซ่โฆษณาแห่งความรับผิดชอบอยู่ในใจ
Mchl

3
@Mchl: โปรดโพสต์คำตอบของคุณเป็นคำตอบไม่ใช่ความคิดเห็น
S.Lott

คุณควรดูMefและข้อมูล MSDN
Luc Bos

ฉันรู้สึกว่ามันไม่ละเอียดพอสำหรับเรื่องนั้น
Mchl

@Mchl: "มีรายละเอียดไม่เพียงพอ" แล้วทำไมถึงแสดงความคิดเห็นทั้งหมด? มันเป็นคำตอบที่ชัดเจน กรุณาโพสต์คำตอบเป็นคำตอบ
S.Lott

คำตอบ:


13

มันขึ้นอยู่กับแพลตฟอร์มของคุณ แต่บางสิ่งทั่วไปที่ต้องจำไว้

การกำหนดเวอร์ชัน จะเกิดอะไรขึ้นหากคุณอัปเดตแอปพลิเคชันของคุณปลั๊กอินเก่าทั้งหมดจะล้าสมัย (ปัญหา Firefox)

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

การอัพเดต คุณจัดการกับ plugin-updates ได้อย่างไร?

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

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

ความสามารถ ด้านใดที่คุณจำเป็นต้องขยาย คุณจะเพิ่มศักยภาพสูงสุดของปลั๊กอินโดยไม่ต้อง API กลายเป็นเทอะทะได้อย่างไร

หากคุณกำหนดเป้าหมายไปที่นักพัฒนาบุคคลที่สามสำหรับปลั๊กอินฉันพูดได้ว่าสิ่งที่สำคัญที่สุด (จากประสบการณ์ของฉัน) คือการดูปลั๊กอิน api และคลาสที่แตกต่างอย่างสิ้นเชิงจากส่วนที่เหลือของแอปพลิเคชันและทำให้ง่ายต่อการพัฒนา เป็นไปได้. มันง่ายมากสำหรับสถาปัตยกรรมตั้งแต่แอปหลักไปจนถึง "ตกเลือด" ลงในปลั๊กอินเพื่อให้ผู้เขียนปลั๊กอินต้องเรียนรู้มากกว่าที่พวกเขาต้องการ ทำให้เป็นเรื่องง่ายสำหรับพวกเขาคิดเกี่ยวกับชนิดของอินเทอร์เฟซและประสบการณ์ที่คุณต้องการในฐานะผู้เขียนปลั๊กอิน

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

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


1
+1 มันไม่ได้ตอบคำถามโดยตรง แต่สิ่งเหล่านี้เป็นประเด็นสำคัญที่ต้องคำนึงถึง
Adriano Carneiro

ฉันเชื่อว่าปัญหาเหล่านี้ได้รับการคุ้มครองก่อนที่ใครจะเริ่มพัฒนากลไกการขยายตัวจริง
กัส

9

ฉันเขียนบทความ Code Project นี้เกี่ยวกับการใช้ MEF สำหรับการเพิ่มความสามารถใน. NET มันเป็นการแนะนำที่ดี

มีกรอบการขยายอื่น ๆ สำหรับ NET, เช่นSharpDevelop ของเพิ่มในสถาปัตยกรรม , Mono.AddinsและSystem.AddIn

สำหรับ Java, มีคราส Plug-in สถาปัตยกรรม

รูปแบบทั่วไปคือ:

  • คุณกำหนดสัญญา (โดยปกติจะเป็นอินเตอร์เฟส) ระหว่างโฮสต์และส่วนขยาย
  • คุณต้องมีกลไกการค้นพบที่ดับและค้นหาส่วนขยายที่ติดตั้ง
  • คุณต้องสามารถโหลดส่วนขยายแบบไดนามิกและทำให้โฮสต์ตระหนักถึงส่วนขยายเหล่านั้น

ในทางปฏิบัติมันมีจำนวนมากด้วยการพึ่งพาการฉีดและรูปแบบกลยุทธ์


+1 MEF และ System.AddIn เป็นทั้งสิ่งที่ควรดู แม้ว่าคุณจะไม่ได้ใช้มันพวกเขาทั้งคู่แสดงแนวคิดที่ดี
RationalGeek

@jkohlhepp - ฉันเห็นด้วยและฉันขอแนะนำการดำน้ำลึกในสถาปัตยกรรม SharpDevelop เพราะมีการเขียนจำนวนมากเกี่ยวกับมันเป็นโอเพนซอร์ส (เช่น MEF, btw) และได้รับการออกแบบมาอย่างดี
Scott Whitlock

3

คุณเพียงแค่ต้องจัดเตรียมส่วนต่อประสานสำหรับปลั๊กอิน

มันควรมีอย่างน้อย Activate-Methode (จุดเข้าใช้งาน) แต่คุณจะต้องการสิ่งต่าง ๆ เช่นเริ่มต้นเป็นต้น

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

นอกจากนี้ควรมีที่เก็บข้อมูลที่เข้าถึงได้สำหรับข้อมูลและวัตถุของแอปพลิเคชันโฮสต์ดังนั้นปลั๊กอินสามารถเรียกรูทีนได้ สิ่งนี้สามารถทำได้อย่างง่ายดายโดยใช้ DI-Container เช่น Unity และปล่อยให้ปลั๊กอินเข้าถึงเพื่อให้สามารถแก้ไขบริการที่ต้องการได้

Event-Aggregator อาจเป็นความคิดที่ดีดังนั้นปลั๊กอินสามารถสร้างเหตุการณ์และตอบสนองต่อเหตุการณ์จากปลั๊กอินอื่น ๆ และแอปพลิเคชันโฮสต์ในลักษณะแยกกัน คุณต้องการหนึ่งอย่างแน่นอน!

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.