Я ищу помощи, чтобы решить, какая структура внедрения зависимостей лучше всего соответствует нашим потребностям, и стоит ли идти по этому пути в первую очередь.

Настраивать:

Я работаю с кодовой базой из ~ 300 тыс. строк кода. У нас есть множество «основных» клиентов, а также дополнительный крупный клиент. Для последнего требовалась отдельная версия нашего программного обеспечения, которую мы затем предоставили.

С тех пор появилась перспектива сотрудничества с другими партнерами. В будущем для некоторых из них могут потребоваться индивидуальные версии программного обеспечения — от простого дизайна пользовательского интерфейса до исключения больших разделов функциональности.

Поэтому в настоящее время мы стремимся к модуляции нашей кодовой базы, предпочтительно используя внедрение зависимостей (DI).

Кодовая база написана на Java, однако мы используем JNI и реализуем большую часть функциональности на C++. Это следует учитывать при принятии решения о пригодности фреймворка.

В настоящее время мы в основном стремимся к модуляризации продуктовых линеек, то есть больших разделов нашей кодовой базы. На практике, однако, очень вероятно, что будет модульность средних и мелких функций.

Расследование

На данный момент предпочтение отдается решению DI, хотя это не является обязательным требованием. Фреймворки, которые я изучаю, в основном:

• Кинжал 2
• Обличье
• Весна ДИ

Помимо них есть еще решения, которые хотя бы вкратце рассмотрены:

• Коин
• CDI Java EE6
• Зубочистка

Аспекты, которые мы рассматриваем:

• Возможность модульности
• Усилия по использованию фреймворка в большой кодовой базе
• Производительность, особенно по использованию памяти
• Обфускация кода (не высший приоритет, однако возникли некоторые подозрения, не пытался ли один из наших клиентов декомпилировать наш код, поэтому нам придется рассмотреть и это тоже)

Кинжал 2

Пока это кажется фаворитом. Платформа избегает отражения, что желательно, особенно в отношении использования памяти, поскольку это ограничение ресурсов для наших клиентов.

Отладка Dagger 2 кажется проще, чем с Spring и Guise, из-за надлежащей трассируемости и их акцента на удобочитаемых именах классов.

И последнее, но не менее важное: существует способ запутать код с помощью ProGuard. Также сведен к минимуму шаблонный код.

Однако я рассматриваю кривую обучения Dagger 2, поскольку некоторые утверждают, что она может иметь высокую степень сложности. Также кажется, @Overrideчто Dagger 2 не поддерживает его, что приводит к необходимости дополнительного рефакторинга, поскольку такие классы необходимо будет разделить на модули, если они будут внедрены.

Также проблема заключается в поиске ошибок только во время выполнения, если что-то пойдет не так с инъекцией. Это может привести к тому, что клиенты столкнутся с ошибками во время выполнения, которые остались незамеченными при подготовке.

Обличье

Как и Spring DI, у Guise уже есть большое сообщество, чего может не хватать Dagger 2, поэтому поиск ответов на вопросы может быть проще. Большим преимуществом Spring DI является соединение классов с использованием информации о типах.

Однако, как и Spring DI, Guise использует отражение, поэтому с точки зрения производительности это не так уж хорошо. Для соображений, связанных с памятью, это минус.

Разработчики Dagger 2 утверждают, что сосредоточили внимание на улучшении возможностей отладки. Они также утверждают, что с Guise некоторые точки останова могут быть даже не поняты при выполнении. Поэтому некоторые приложения, использующие Guise, могут вообще не подходить для целей отладки.

Весна ДИ

Похоже, это старожил среди фреймворков. За Spring стоит огромное сообщество, поэтому, скорее всего, все будет хорошо задокументировано, а ответы легко найти в Интернете. Однако сообщество Spring выглядит довольно неактивным, а это означает, что, хотя в Интернете доступно много ответов, новые найти трудно.

Framework использует XML, хотя я читал, что есть возможность использовать аннотации. Оба случая являются отражением, поэтому снова не оптимальны при рассмотрении использования ОЗУ.

Функциональность, такая как F3 Eclipse, недоступна при работе с внедренными зависимостями. Есть Spring IDE, но это вообще не вариант.

Spring DI поставляется с большим количеством шаблонного кода, что заслуживает внимания с нашей кодовой базой из 300 тысяч строк.

Вопросы

В основном я хотел бы услышать ваше мнение об этих фреймворках, независимо от того, рекомендуете ли вы их и считаете ли вы, что какие-либо из них подходят для описанной мной задачи. Эти вещи меня особенно интересуют:

• Подходят ли эти фреймворки для модуляризации, которую мы намереваемся достичь?
• Так ли заметна разница в производительности, как кажется?
• Есть ли какие-либо важные факторы, которые я должен учитывать при выборе фреймворка, которые еще не упомянуты? Возможно, некоторые из вас видят типичные трудности при работе с DI, которые очевидны для вас в отношении нашей установки, но не очевидны для меня в данный момент.
• Предлагают ли Spring DI или Guise запутывание кода? И так ли легко включить ProGuard, как утверждается?
• Следует ли серьезно рассматривать другие фреймворки, учитывая кодовую базу, как описано?

В общем, я благодарен за любую информацию по этой теме, так как я не эксперт по DI. Если вы видите какие-либо красные флажки в этом описании, особенно вопиющие причины того, почему любой из доступных фреймворков абсолютно не подходит в нашем случае, то это ценная информация.

Спасибо.