Google Guice กับ PicoContainer สำหรับ Dependency Injection

ทีมของฉันกำลังค้นคว้าเกี่ยวกับกรอบการพึ่งพาการฉีดขึ้นรูปและกำลังพยายามตัดสินใจระหว่างการใช้ Google-Guice และ PicoContainer

เรากำลังมองหาหลายสิ่งในกรอบของเรา:

1. รอยเท้ารหัสขนาดเล็ก - สิ่งที่ฉันหมายถึงรอยเท้ารหัสขนาดเล็กคือเราไม่ต้องการให้มีการฉีดรหัสการพึ่งพาทุกที่ในฐานรหัสของเรา หากเราจำเป็นต้องปรับโครงสร้างใหม่บนท้องถนนเราต้องการให้ง่ายที่สุด
2. ประสิทธิภาพ - แต่ละเฟรมเวิร์กมีค่าใช้จ่ายเท่าใดเมื่อสร้างและฉีดวัตถุ?
3. ใช้งานง่าย - มีเส้นการเรียนรู้ขนาดใหญ่หรือไม่? เราต้องเขียนโค้ดเพื่อให้ทำงานง่าย ๆ หรือไม่? เราต้องการให้มีการกำหนดค่าน้อยที่สุด
4. ขนาดชุมชน - ชุมชนที่ใหญ่ขึ้นมักจะหมายความว่าโครงการจะยังคงได้รับการดูแลต่อไป เราไม่ต้องการใช้เฟรมเวิร์กและต้องแก้ไขข้อบกพร่องของเราเอง) นอกจากนี้คำถามใด ๆ ที่เรามีระหว่างทางก็สามารถ (หวังว่า) จะได้รับคำตอบจากชุมชนผู้พัฒนา / ผู้ใช้ของเฟรมเวิร์ก

การเปรียบเทียบสองกรอบกับเกณฑ์ที่ระบุไว้จะได้รับการชื่นชมอย่างมาก ประสบการณ์ส่วนตัวใด ๆ ที่ช่วยเปรียบเทียบทั้งสองอย่างก็จะเป็นประโยชน์อย่างยิ่ง

ข้อจำกัดความรับผิดชอบ: ฉันค่อนข้างใหม่สำหรับการฉีดพึ่งพาดังนั้นขอโทษที่ไม่มีใครรู้ว่าฉันถามคำถามที่ไม่ตรงกับการสนทนานี้

คุณอาจต้องการรวม Spring ไว้ในรายการกรอบงาน Dependency Injection ที่คุณกำลังพิจารณา คำตอบสำหรับคำถามของคุณมีดังนี้

การเชื่อมต่อกับกรอบ

Pico - Pico มีแนวโน้มที่จะกีดกันการฉีด setter แต่นอกเหนือจากนั้นชั้นเรียนของคุณไม่จำเป็นต้องรู้เกี่ยวกับ Pico เป็นเพียงการเดินสายที่จำเป็นต้องรู้ (จริงสำหรับเฟรมเวิร์ก DI ทั้งหมด)

Guice - Guice รองรับคำอธิบายประกอบJSR 330มาตรฐานแล้วดังนั้นคุณไม่จำเป็นต้องมีคำอธิบายประกอบเฉพาะของ Guice ในโค้ดของคุณอีกต่อไป Spring ยังรองรับคำอธิบายประกอบมาตรฐานเหล่านี้ ข้อโต้แย้งที่ Guice ใช้คือการที่ไม่มีตัวประมวลผลคำอธิบายประกอบ Guice ทำงานอยู่สิ่งเหล่านี้ไม่ควรมีผลกระทบหากคุณตัดสินใจใช้กรอบงานอื่น

Spring - Spring มีจุดมุ่งหมายเพื่อให้คุณหลีกเลี่ยงการกล่าวถึง Spring framework ในโค้ดของคุณ เนื่องจากพวกเขามีตัวช่วย / สาธารณูปโภคอื่น ๆ อีกมากมายสิ่งล่อใจนั้นค่อนข้างแข็งแกร่งที่จะขึ้นอยู่กับรหัส Spring แม้ว่า

ประสิทธิภาพ

Pico - ฉันไม่ค่อยคุ้นเคยกับลักษณะความเร็วของ Pico

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

ฤดูใบไม้ผลิ - ฤดูใบไม้ผลิอาจช้า มีงานที่ต้องทำให้เร็วขึ้นและการใช้ไลบรารี JavaConfig ควรเร่งความเร็ว

สะดวกในการใช้

Pico - ง่ายต่อการกำหนดค่า Pico สามารถตัดสินใจโดยอัตโนมัติให้คุณได้ ไม่ชัดเจนว่าจะปรับขนาดเป็นโครงการขนาดใหญ่มากอย่างไร

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

Spring - ค่อนข้างง่ายในการกำหนดค่า แต่ตัวอย่างส่วนใหญ่ใช้ Spring XML เป็นวิธีการกำหนดค่า ไฟล์ Spring XML อาจมีขนาดใหญ่และซับซ้อนเมื่อเวลาผ่านไปและต้องใช้เวลาในการโหลด ลองใช้ส่วนผสมของ Spring และ Dependency Injection เพื่อเอาชนะสิ่งนี้

ขนาดชุมชน

ปิโก - เล็ก

Guice - ปานกลาง

สปริง - ขนาดใหญ่

ประสบการณ์

Pico - ฉันไม่ค่อยมีประสบการณ์กับ Pico มากนัก แต่ไม่ใช่เฟรมเวิร์กที่ใช้กันอย่างแพร่หลายดังนั้นจึงหาทรัพยากรได้ยากขึ้น

Guice - Guice เป็นเฟรมเวิร์กยอดนิยมและยินดีที่จะให้ความสำคัญกับความเร็วเมื่อคุณมีโปรเจ็กต์ขนาดใหญ่ที่คุณกำลังรีสตาร์ทจำนวนมากในการพัฒนา ฉันมีข้อกังวลเกี่ยวกับลักษณะการกระจายของการกำหนดค่านั่นคือไม่ง่ายเลยที่จะดูว่าแอปพลิเคชันทั้งหมดของเรารวมเข้าด้วยกันอย่างไร มันคล้ายกับ AOP ในแง่นี้

ฤดูใบไม้ผลิ - ฤดูใบไม้ผลิมักจะเป็นตัวเลือกเริ่มต้นของฉัน กล่าวได้ว่า XML อาจยุ่งยากและส่งผลให้เกิดการชะลอตัวที่น่ารำคาญ ฉันมักจะลงเอยด้วยการผสมผสานระหว่าง Dependency Injection และ Spring ที่สร้างขึ้นด้วยมือ เมื่อคุณต้องการการกำหนดค่าตาม XML จริง Spring XML ค่อนข้างดี Spring ยังใช้ความพยายามอย่างมากในการทำให้เฟรมเวิร์กอื่น ๆ เป็นมิตรกับ Dependency Injection ซึ่งมีประโยชน์เนื่องจากมักใช้แนวทางปฏิบัติที่ดีที่สุดเมื่อทำเช่นนั้น (JMS, ORM, OXM, MVC เป็นต้น)

อ้างอิง

• ปิโก
• Guice
• ฤดูใบไม้ผลิ
• การเปรียบเทียบ Spring / Guice / Pico
• การเปรียบเทียบประสิทธิภาพ Spring / Guice อื่น ๆ

คำตอบที่นำเสนอโดย jamie.mccrindle นั้นค่อนข้างดี แต่ฉันรู้สึกสับสนว่าทำไม Spring จึงเป็นตัวเลือกเริ่มต้นเมื่อค่อนข้างชัดเจนว่ามีทางเลือกที่เหนือกว่า (ทั้ง Pico และ Guice) ความนิยมของ IMO Spring ถึงจุดสูงสุดแล้วและตอนนี้ก็กำลังอยู่ในช่วงโฆษณาที่สร้างขึ้น (พร้อมกับโปรเจ็กต์ย่อย Spring "me too" อื่น ๆ ที่ต้องการขี่ Spring bandwagon)

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

ขนาดที่เล็กและการขาดการพึ่งพาของ Pico เป็นชัยชนะที่สำคัญซึ่งไม่ควรพูดมาก คุณต้องดาวน์โหลดกี่ megs เพื่อใช้ Spring ตอนนี้? มันเป็นความยุ่งเหยิงของไฟล์ jar ขนาดใหญ่ที่มีการอ้างอิงทั้งหมด การคิดโดยสังหรณ์ใจวิธีแก้ปัญหาที่มีประสิทธิภาพและ "เล็ก" เช่นนี้ควรปรับขนาดและทำงานได้ดีกว่าสปริง การขยายตัวของ Spring จะทำให้ขนาดดีขึ้นจริงหรือ? โลกที่แปลกประหลาดนี้หรือไม่? ฉันจะไม่ตั้งสมมติฐานว่า Spring นั้น "ปรับขนาดได้มากกว่า" จนกว่าจะได้รับการพิสูจน์ (และอธิบาย)

บางครั้งการสร้างสิ่งที่ดี (Pico / Guice) แล้วทำให้มือของคุณไม่อยู่ในนั้นแทนที่จะเพิ่มคุณสมบัติขยายตัวและอ่างล้างจานด้วยเวอร์ชันใหม่ที่ไม่มีที่สิ้นสุดก็ได้ผลจริงๆ ...

หมายเหตุ: นี่เป็นความคิดเห็น / คุยโวมากกว่าคำตอบ

PicoContainer เยี่ยมมาก ฉันจะเปลี่ยนกลับไปใช้ถ้าพวกเขาแค่แก้ไขเว็บไซต์ ตอนนี้สับสนจริงๆ:

• http://picocontainer.comซึ่งเป็นหน้าเว็บล่าสุด แต่หลาย ๆ หน้ามีปัญหาในการจัดรูปแบบและบางหน้าใช้งานไม่ได้เลย ดูเหมือนว่าหน้าเว็บจะถูกแปลงโดยอัตโนมัติจากเนื้อหาเก่า
• http://picocontainer.codehaus.org/ซึ่งดูเหมือนจะหยุดนิ่งในเวลาที่เวอร์ชัน 2.10.2 - คงจะดีมากหากหน้าเว็บดังกล่าวมีข้อความเช่น "เดี๋ยวก่อนคุณกำลังดูเว็บไซต์เก่าอยู่!"
• http://docs.codehaus.org/display/PICO/Home - วิกิที่มาบรรจบกันที่เอกสาร v 1.x แต่ไม่ได้บอกว่าทุกที่บนหน้า!

ตอนนี้ฉันใช้ Guice 2.x แม้ว่าจะใหญ่กว่าและมีคุณสมบัติน้อยกว่า การค้นหาเอกสารนั้นง่ายกว่ามากและกลุ่มผู้ใช้ก็มีการใช้งานมาก อย่างไรก็ตามหากทิศทางของ Guice 3 เป็นข้อบ่งชี้ใด ๆ ดูเหมือนว่า Guice จะเริ่มขยายตัวเช่นเดียวกับที่ Spring ย้อนกลับไปในช่วงแรก ๆ

อัปเดต: ฉันโพสต์ความคิดเห็นไปยังชาว Pico Container และพวกเขาได้ทำการปรับปรุงเว็บไซต์ ดีขึ้นมากแล้ว!

เป็นคำถามเก่า แต่วันนี้คุณสามารถพิจารณา Dagger ( https://github.com/square/dagger ) ในโครงการ Android App ของคุณ Dagger สร้างรหัสตามเวลารวบรวม ดังนั้นคุณจะได้รับเวลาเริ่มต้นที่สั้นลงและใช้หน่วยความจำน้อยลงในเวลาดำเนินการ

ถ้าคุณหลังจากภาชนะ DI minimalistic คุณสามารถตรวจสอบขนนก ฟังก์ชัน Vanilla JSR-330 DI เท่านั้น แต่ค่อนข้างดีในแง่ของรอยเท้า (16K ไม่มีการอ้างอิง) และประสิทธิภาพ ทำงานบน Android

แม้ว่าฉันจะชอบ PicoContainer เพราะมันเรียบง่ายและขาดการพึ่งพา ฉันอยากจะแนะนำให้ใช้ CDI แทนเนื่องจากเป็นส่วนหนึ่งของมาตรฐาน Java EE ดังนั้นคุณจึงไม่มีการล็อกผู้ขาย

ในแง่ของการล่วงล้ำปัญหาหลักคือความต้องการของคอนเทนเนอร์และการใช้ไฟล์ META-INF / beans.xml ที่ค่อนข้างว่างเปล่า (จำเป็นเพื่อระบุว่า jar ใช้ CDI) และการใช้คำอธิบายประกอบ (แม้ว่าจะเป็นมาตรฐาน )

คอนเทนเนอร์ CDI น้ำหนักเบาที่ฉันใช้สำหรับโครงการของตัวเองคือ Apache Open Web Beans แม้ว่าจะใช้เวลาสักพักในการหาวิธีสร้างแอปง่ายๆ (ไม่เหมือน Pico) ซึ่งมีลักษณะเช่นนี้

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}