Кто-нибудь использует Qi4J
Ранее я читал статью InfoQ о композитно-ориентированном программировании:
http://www.infoq.com/articles/Composite-Programming-Qi4j
Мне было интересно узнать, использует ли кто-либо в настоящее время (или использовал) фреймворк Qi4j вообще?
Как это сравнивается с использованием традиционной структуры внедрения зависимостей, такой как Spring, для связывания классов вместе. Легче ли работать с результирующим графом объектов (основанным на миксинах, а не на классах) с точки зрения обслуживания?
6 ответов
Ну, я сам использую Qi4j около года в проекте. Когда вы привыкнете к силе миксинов в своей доменной модели, вы будете удивляться, как раньше обходились без них. На самом деле, я думаю, что POJO-метод создания доменных моделей должен быть устаревшим. Создает системно не поддерживаемый код. Поскольку смешанная / составная модель является важной особенностью Qi4j, а не DI, на платформе Java нет никакого сравнения.
Что касается опасений Божо: когда дело доходит до объявления миксинов, есть два отдельных случая. В сущностях, то есть в модели предметной области, интерфейс, как правило, имеет только одну реализацию, и вы на самом деле хотите активно избегать использования нескольких реализаций в целях обслуживания и читабельности. Поэтому я объявляю реализацию прямо в интерфейсе. Но это только значение по умолчанию, которое может быть переопределено композитом, если вы хотите. Я до сих пор никогда не нашел в этом необходимости.
Другой случай - услуги, которые совсем другие. Во многих случаях будет только одна реализация, и поэтому объявление реализации в интерфейсе снова вполне нормально. Но есть гораздо больше случаев со службами, для которых вам нужны разные реализации, и поэтому для этих случаев вы просто объявляете mixin в объявлении конкретного составного типа. Так что оба стиля возможны и рекомендуются по разным причинам.
Что касается каста, то способность кастовать объект является бонусом, а не проблемой. Если у вас нет перехода от одной роли к другой, вам придется проявить изобретательность, чтобы обойти это, что, вероятно, не сделает ваш код проще.
Kabram; Интеграция с JPA была предпринята несколько раз. Если у нас есть две частично совпадающие, но не полностью совместимые технологии, вы получите только пересечение возможностей. Итак, есть два основных подхода к интеграции Qi4j с JPA.
Чтобы ограничить параметры JPA, чтобы можно было в полной мере использовать гораздо более гибкие структуры данных, в которых нуждается Qi4j. Делать это не имеет смысла, поскольку переход непосредственно к SQL намного более производительный, и это то, что мы выбрали.
Ограничить модель данных Qi4j для соответствия существующей модели данных JPA. Это лишит большинство преимуществ того, почему люди выбирают Qi4j в первую очередь. Поэтому мы решили не тратить на это циклы. Тем не менее, я думаю, что расширяемость Qi4j достаточно хороша для такой интеграции без взлома в Core Runtime и простого создания EntityStore.
Надеюсь, не слишком поздно для этой дискуссии: но это то, как я это вижу.
Прежде всего мне нравятся идеи (композиты, миксины, сборки), лежащие в основе Qi4j, но меня сдерживает сложность его использования.
Понятия должны быть частью более широкого зонтика, такого как язык (например, Java), чем фреймворк, и должны быть более простыми в использовании.
Я столкнулся с проблемой 2 года назад, которая оставила меня, желая что-то подобное тогда.
Я хотел 3 разных поведения, которые можно было бы повторно использовать на наборе компонентов. Некоторые бобы использовали их все другие, любое сочетание двух. Я не хотел собирать их всех вместе в классе, потому что это не имело смысла. С другой стороны, я был ограничен тем фактом, что я не мог иметь множественное наследование. Очевидное решение: использовать интерфейс; что означает реализовать вещь, которая много раз. Я не забываю жаловаться коллеге на тот факт, что надеюсь, что у меня был способ обеспечить реализацию интерфейса по умолчанию. Для меня это простая концепция ОО, которая позволяет более рационально использовать поведение. И если это тот случай, когда вам нужно что-то отличное от реализации по умолчанию, чем реализовать это. Это имело бы больше смысла и не нарушало бы никакого естественного закона, который я могу видеть.
Поэтому, чтобы ответить на ваш вопрос, я думаю, что концепции этого Qi4j позволяют вам мыслить ОО более чистым способом, где Spring более структурный и даже не сопоставим концептуально. Вы можете думать о инъекции зависимости, не думать о весне и думать о Qi4j, а не думать о глубокой инъекции.
Когда я прочитал учебники по Qi4j за 2 минуты, 10 минут и т. Д. (Последний из них не завершен), возник один очевидный вопрос: как мне интегрировать это с управляемыми объектами JPA/Hibernate? Я хотел бы увидеть решение, которое легко интегрируется с JPA. По моему мнению, отсутствие JPA не означает принятия Qi4j. Мне бы очень хотелось увидеть статью автора (ов), в которой показана интеграция с JPA и Spring, двумя вещами, которые глубоко проникли в мир Java Enterprise. Если интеграция проста, быстрое принятие последует.
Прочитав первую часть связанной статьи, мне не понравились две вещи:
- реализации определены в интерфейсе (используя
@Mixins) - что, если они должны быть осмеяны или реализации изменены? - требует кастинга
Не имея опыта работы с Qi4J, я не могу сказать, как это получается на практике, но это не очень хорошо.
Bozho; Для вас вопрос о том, что Mixins были объявлены на интерфейсах,
Реализации Mixin могут быть переопределены, либо в "более высоких" (то есть под) интерфейсах, так как порядок поиска для реализаций происходит "для метода" и идет от объявленного интерфейса слева направо, а затем к каждому из супер интерфейсы (также слева направо в предложении extends). ИЛИ, вы можете переопределить в сборке композита;
public void assemble( ModuleAssembly module )
{
module.entities( Account.class ).withMixins( LdapAuthenticatorMixin.class );
:
}
где LdapAuthenticatorMixin может быть абстрактным и переопределять только один метод.