Google Guice по сравнению с PicoContainer для внедрения зависимости
Моя команда исследует платформы внедрения зависимости и пытается решить между использованием Google-Guice и PicoContainer.
Мы ищем несколько вещей в нашей платформе:
- Маленькое место кода - Что я подразумеваю под маленьким местом кода, мы не хотим иметь мусор кода внедрения зависимости везде в нашей кодовой базе. Если мы должны осуществить рефакторинг в будущем, мы хотим, чтобы это было максимально легко.
- Производительность - Сколько наверху каждая платформа имеет при создании и введении объектов?
- Простота использования - Является там большой кривой обучения? Мы должны записать насыпи кода для получения чего-то простая работа? Мы хотим иметь как можно меньше конфигурацию.
- Общественный размер - Более многочисленные сообщества обычно подразумевают, что проект продолжит сохраняться. Мы не хотим использовать платформу и иметь для исправления наших собственных ошибок ;) Также на любые вопросы, которые мы имеем по пути, может (надо надеяться), ответить сообщество разработчика/пользователя платформы.
Сравнения этих двух платформ против перечисленных критериев значительно ценились бы. Любой личный опыт, который помогает сравнить эти два, также был бы чрезвычайно полезен.
Отказ от ответственности: Я довольно плохо знаком с внедрением зависимости, так извините мой мыс новичка, если я задал вопрос, который не является подходящим для этого обсуждения.
2 ответа
Возможно, вы захотите включить Spring в список рассматриваемых вами фреймворков зависимостей. Вот некоторые ответы на ваши вопросы:
Подключение к фреймворку
Pico - Пико, как правило, препятствует инъекции сеттера, но в остальном, вашим классам не нужно знать о Пико. Знать нужно только проводку (верно для всех фреймворков DI).
Guice - Guice теперь поддерживает стандартные JSR 330 аннотации, так что вам больше не нужны аннотации для Guice в вашем коде. Весна также поддерживает эти стандартные аннотации. Аргумент, который используют парни из Guice, заключается в том, что без запущенного процессора аннотаций Guice, это не должно влиять, если вы решите использовать другой фреймворк.
Spring - Цель Spring - позволить вам избежать любого упоминания фреймворка Spring в вашем коде. Поскольку у них есть много других помощников, утилит и т.д., соблазн сильно зависеть от кода Spring.
Performance
Pico - я не слишком хорошо знаком со скоростными характеристиками Pico
Guice - Guice был задуман как быстрый, и сравнение, упомянутое в ссылке, имеет несколько чисел. Конечно, если скорость является основным соображением, либо с использованием Guice, либо проводкой вручную, то следует учитывать
Spring - Пружина может быть медленной. Была проделана работа по ее ускорению, и использование библиотеки JavaConfig должно все ускорить.
Простота использования
Pico - Простота настройки. Pico может принимать за вас некоторые решения по автопроводке. Непонятно, как она масштабируется до очень больших проектов.
Guice - Простота настройки, вы просто добавляете аннотации и наследуете от AbstractModule, чтобы связать вещи вместе. Масштабируется хорошо для больших проектов, так как конфигурация сведена к минимуму.
Spring - Относительно легко конфигурируется, но в большинстве примеров в качестве метода конфигурации используется Spring XML. Файлы XML пружины могут стать очень большими и сложными со временем и потребовать времени на загрузку. Рассмотрим возможность использования смеси весны и ручной кривошип ввода зависимости для преодоления этого.
Размер сообщества
Пико - Маленький
Гуис - Средний
Весна - Большой
Опыт
Пико - У меня не было большого опыта работы с Пико, но это не очень распространенный фреймворк, так что будет сложнее найти ресурсы.
Guice - Guice - популярный фреймворк, и его ориентация на скорость приветствуется, когда у вас есть большой проект, который вы много перезапускаете в разработке. Меня беспокоит распределённая природа конфигурации, т.е. не так просто увидеть, как всё наше приложение собрано воедино. В этом отношении это немного похоже на AOP.
Весна - Весна обычно является моим выбором по умолчанию. Тем не менее, XML может стать громоздким и в результате замедление будет раздражать. Я часто использую комбинацию ручной инжекции зависимостей и весны. Когда Вам действительно нужна основанная на XML конфигурация, Spring XML довольно хорош. Весна также приложила много усилий, чтобы сделать другие фреймворки более дружественными к внедрению зависимостей, которые могут быть полезны, потому что они часто используют лучшие методы, когда делают это (JMS, ORM, OXM, MVC и т.д.).
Ссылки
Ответ jamie.mccrindle на самом деле довольно хорош, но я не понимаю, почему Spring является выбором по умолчанию, когда совершенно очевидно, что доступны превосходные альтернативы (как Pico, так и Guice) . Популярность IMO Spring достигла своего пика, и теперь она в настоящее время живет за счет созданной шумихи (вместе со всеми другими подпроектами Spring «я тоже», стремящимися оседлать подножку Spring).
Единственное реальное преимущество Spring - это размер сообщества (и, честно говоря, он необходим из-за размера и сложности), но Пико и Гайсу не нужно огромное сообщество, потому что их решение намного чище, более организованный и элегантный. Pico кажется более гибким, чем Guice (вы можете использовать аннотации в Pico или нет - это чрезвычайно эффективно). (Edit: имелось в виду, что он чрезвычайно гибкий, но не то, что он также неэффективен.)
Крошечный размер Pico и отсутствие зависимостей - это ГЛАВНАЯ победа, которую нельзя недооценивать. Сколько мегабайт вам нужно загрузить, чтобы использовать Spring сейчас? Это беспорядок из огромных jar-файлов со всеми их зависимостями. При интуитивном мышлении такое эффективное и «маленькое» решение должно масштабироваться и работать лучше, чем что-то вроде Spring. Действительно ли раздувание Spring улучшит масштабирование? Это причудливый мир? Я бы не стал делать предположений, что Spring «более масштабируем», пока это не будет доказано (и объяснено).
Иногда действительно получается создать что-то хорошее (Pico / Guice), а затем держать руки в стороне от этого вместо того, чтобы добавлять навороты и функции кухонной раковины с бесконечными новыми версиями ...