Google Guice so với PicoContainer cho Dependency Injection

Nhóm của tôi đang nghiên cứu các khuôn khổ chèn phụ thuộc và đang cố gắng quyết định giữa việc sử dụng Google-Guice và PicoContainer.

Chúng tôi đang tìm kiếm một số thứ trong khuôn khổ của mình:

1. Một dấu chân mã nhỏ - Ý tôi nói về một dấu chân mã nhỏ là chúng ta không muốn có hàng đống mã tiêm phụ thuộc ở khắp mọi nơi trong cơ sở mã của chúng ta. Nếu chúng tôi cần tái cấu trúc lại, chúng tôi muốn nó trở nên dễ dàng nhất có thể.
2. Hiệu suất - Mỗi khung công tác có bao nhiêu chi phí khi tạo và chèn các đối tượng?
3. Dễ sử dụng - Có đường cong học tập lớn không? Chúng ta có phải viết nhiều đoạn mã để có được thứ gì đó hoạt động đơn giản không? Chúng tôi muốn có cấu hình càng ít càng tốt.
4. Quy mô cộng đồng - Các cộng đồng lớn hơn thường có nghĩa là một dự án sẽ tiếp tục được duy trì. Chúng tôi không muốn sử dụng một khuôn khổ và phải sửa các lỗi của chính mình;) Ngoài ra, bất kỳ câu hỏi nào mà chúng tôi có trong quá trình này có thể (hy vọng) được cộng đồng nhà phát triển / người dùng của khuôn khổ trả lời.

So sánh hai khuôn khổ với các tiêu chí được liệt kê sẽ được đánh giá rất cao. Bất kỳ kinh nghiệm cá nhân nào giúp so sánh cả hai cũng sẽ cực kỳ hữu ích.

Tuyên bố từ chối trách nhiệm: Tôi còn khá mới với việc tiêm phụ thuộc vì vậy xin thứ lỗi cho bạn bè của tôi nếu tôi đã hỏi một câu hỏi không liên quan đến cuộc thảo luận này.

Bạn có thể muốn đưa Spring vào danh sách các khuôn khổ Dependency Injection mà bạn đang xem xét. Dưới đây là một số câu trả lời cho câu hỏi của bạn:

Khớp nối với khuôn khổ

Pico - Pico có xu hướng không khuyến khích tiêm setter nhưng ngoài điều đó, các lớp học của bạn không cần biết về Pico. Đó chỉ là cách nối dây cần biết (đúng với tất cả các khung DI).

Guice - Guice hiện hỗ trợ các chú thích JSR 330 tiêu chuẩn , vì vậy bạn không cần chú thích cụ thể của Guice trong mã của mình nữa. Spring cũng hỗ trợ các chú thích tiêu chuẩn này. Lập luận mà những người của Guice sử dụng là không có bộ xử lý chú thích Guice đang chạy, chúng sẽ không có tác động nếu bạn quyết định sử dụng một khung công tác khác.

Spring - Spring nhằm mục đích cho phép bạn tránh mọi đề cập đến khuôn khổ Spring trong mã của bạn. Bởi vì họ có rất nhiều trợ giúp / tiện ích khác, v.v ... nên sự cám dỗ khá mạnh mẽ khi phụ thuộc vào mã Spring.

Hiệu suất

Pico - Tôi không quá rành về các đặc tính tốc độ của Pico

Guice - Guice được thiết kế để nhanh chóng và so sánh được đề cập trong tài liệu tham khảo có một số con số. Chắc chắn nếu tốc độ là yếu tố chính thì nên cân nhắc sử dụng Guice hoặc đấu dây bằng tay

Spring - Mùa xuân có thể đến chậm. Đã có nhiều nỗ lực để làm cho nó nhanh hơn và việc sử dụng thư viện JavaConfig sẽ tăng tốc mọi thứ.

Dễ sử dụng

Pico - Cấu hình đơn giản. Pico có thể đưa ra một số quyết định tự động cho bạn. Không rõ nó có quy mô như thế nào đối với các dự án rất lớn.

Guice - Cấu hình đơn giản, bạn chỉ cần thêm chú thích và kế thừa từ AbstractModule để gắn kết mọi thứ với nhau. Quy mô tốt cho các dự án lớn vì cấu hình được giữ ở mức tối thiểu.

Spring - Tương đối dễ cấu hình nhưng hầu hết các ví dụ đều sử dụng Spring XML làm phương thức để cấu hình. Các tệp Spring XML có thể trở nên rất lớn và phức tạp theo thời gian và cần thời gian để tải. Cân nhắc sử dụng kết hợp Spring và Hand cranked Injection để khắc phục điều này.

Quy mô cộng đồng

Pico - Nhỏ

Guice - Trung bình

Mùa xuân - Lớn

Kinh nghiệm

Pico - Tôi chưa có nhiều kinh nghiệm với Pico nhưng nó không phải là một framework được sử dụng rộng rãi nên việc tìm kiếm tài nguyên sẽ khó hơn.

Guice - Guice là một framework phổ biến và sự tập trung vào tốc độ của nó được hoan nghênh khi bạn có một dự án lớn mà bạn đang khởi động lại rất nhiều trong quá trình phát triển. Tôi có một mối quan tâm về bản chất phân tán của cấu hình, tức là không dễ dàng để xem toàn bộ ứng dụng của chúng ta được kết hợp với nhau như thế nào. Nó hơi giống AOP về mặt này.

Spring - Mùa xuân thường là lựa chọn mặc định của tôi. Điều đó nói rằng, XML có thể trở nên cồng kềnh và gây khó chịu cho việc chạy chậm. Tôi thường sử dụng kết hợp Dependency Injection và Spring được làm thủ công. Khi bạn thực sự cần cấu hình dựa trên XML, Spring XML khá tốt. Spring cũng nỗ lực rất nhiều trong việc làm cho các khung công tác khác thân thiện hơn với Dependency Injection, điều này có thể hữu ích vì họ thường sử dụng phương pháp hay nhất khi làm như vậy (JMS, ORM, OXM, MVC, v.v.).

Người giới thiệu

• Pico
• Guice
• Mùa xuân
• So sánh Spring / Guice / Pico
• Một so sánh hiệu suất khác của Spring / Guice

Câu trả lời được đưa ra bởi jamie.mccrindle thực sự khá tốt, nhưng tôi vẫn bối rối tại sao Spring lại là lựa chọn mặc định khi khá rõ ràng là có sẵn các lựa chọn thay thế cao cấp (cả Pico và Guice). Mức độ nổi tiếng của IMO Spring đã đạt đến đỉnh điểm và hiện tại nó đang sống nhờ vào sự cường điệu được tạo ra (cùng với tất cả các dự án phụ Spring "me too" khác đang tìm cách chèo lái Spring bandwagon).

Lợi thế thực sự duy nhất của Spring là quy mô cộng đồng (và khá thẳng thắn, do quy mô và độ phức tạp, nó cần), nhưng Pico và Guice không cần một cộng đồng lớn vì giải pháp của họ sạch hơn, có tổ chức hơn và thanh lịch hơn nhiều. Pico có vẻ linh hoạt hơn Guice (bạn có thể sử dụng chú thích trong Pico hoặc không - nó cực kỳ hiệu quả). (Chỉnh sửa: Có nghĩa là nó cực kỳ linh hoạt, không phải là nó cũng không hiệu quả.)

Kích thước nhỏ bé và sự thiếu phụ thuộc của Pico là một chiến thắng CHỦ YẾU mà không nên đánh giá thấp. Bạn cần tải xuống bao nhiêu megs để sử dụng Spring bây giờ? Đó là một mớ hỗn độn của các tệp jar khổng lồ, với tất cả các tệp phụ thuộc. Theo trực giác, một giải pháp hiệu quả và "nhỏ" như vậy sẽ mở rộng quy mô và hoạt động tốt hơn một thứ như Spring. Spring's bloat có thực sự giúp nó mở rộng quy mô tốt hơn không? Đây có phải là thế giới kỳ lạ? Tôi sẽ không đưa ra giả định rằng Spring "có thể mở rộng hơn" cho đến khi điều đó được chứng minh (và giải thích).

Đôi khi tạo ra một cái gì đó tốt (Pico / Guice) và sau đó TẮT TẮT nó thay vì thêm các tính năng phình to và bồn rửa nhà bếp với vô số phiên bản mới thực sự hiệu quả ...

LƯU Ý: Đây chỉ là một nhận xét / phản bác hơn là một câu trả lời

PicoContainer là tuyệt vời. Tôi sẽ quay lại nó nếu họ chỉ sửa các trang web của họ. Bây giờ nó thực sự khó hiểu:

• http://picocontainer.com là trang mới nhất, nhưng nhiều trang có vấn đề về định dạng và một số trang không hoạt động. Có vẻ như các trang đã được tự động chuyển đổi từ nội dung cũ hơn.
• http://picocontainer.codehaus.org/ Có vẻ như đã bị đóng băng theo thời gian ở phiên bản 2.10.2 - Sẽ thực sự tuyệt vời nếu các trang nói điều gì đó như "này, bạn đang xem một trang web cũ!"
• http://docs.codehaus.org/display/PICO/Home - Một wiki hợp lưu tài liệu v 1.x, nhưng nó không nói điều đó ở bất kỳ đâu trên các trang!

Tôi đang sử dụng Guice 2.x ngay bây giờ, mặc dù nó lớn hơn và nó có ít tính năng hơn. Việc tìm tài liệu dễ dàng hơn nhiều và nhóm người dùng của nó rất tích cực. Tuy nhiên, nếu định hướng của Guice 3 là bất kỳ dấu hiệu nào, có vẻ như Guice đang bắt đầu nở rộ, giống như Spring đã trở lại trong những ngày đầu.

Cập nhật: Tôi đã đăng một nhận xét cho những người trong Pico Container và họ đã thực hiện một số cải tiến cho trang web. Tốt hơn nhiều bây giờ!

Đó là một câu hỏi cũ nhưng ngày nay bạn có thể xem xét Dagger ( https://github.com/square/dagger ) trong dự án Ứng dụng Android của mình. Dagger thực hiện tạo mã theo thời gian biên dịch. Vì vậy, bạn có được thời gian khởi động ngắn hơn và sử dụng ít bộ nhớ hơn trong thời gian thực thi.

Nếu bạn đang theo đuổi một vùng chứa DI tối giản, bạn có thể xem Feather . Vanilla JSR-330 DI chỉ có chức năng, nhưng khá tốt về diện tích (16K, không có phụ thuộc) và hiệu suất. Hoạt động trên Android.

Mặc dù tôi thích PicoContainer vì nó đơn giản và nó thiếu phụ thuộc. Thay vào đó, tôi khuyên bạn nên sử dụng CDI vì nó là một phần của tiêu chuẩn Java EE, vì vậy bạn không cần phải khóa nhà cung cấp.

Về khả năng xâm nhập, vấn đề chính là yêu cầu của một vùng chứa và việc sử dụng tệp META-INF / bean.xml tương đối trống (cần thiết để chỉ ra rằng jar đang sử dụng CDI) và việc sử dụng các chú thích (mặc dù chúng là tiêu chuẩn )

Bộ chứa CDI nhẹ mà tôi sử dụng cho các dự án của riêng mình là Apache Open Web Beans. Mặc dù phải mất một lúc để tìm ra cách tạo một ứng dụng đơn giản (không giống như Pico) trông như thế này.

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