Кто-нибудь использует Qi4J

Question

Ранее я читал статью InfoQ о композитно-ориентированном программировании:

http://www.infoq.com/articles/Composite-Programming-Qi4j

Мне было интересно узнать, использует ли кто-либо в настоящее время (или использовал) фреймворк Qi4j ?

Как это сравнивается с использованием традиционной структуры внедрения зависимостей, такой как Spring, для связывания классов вместе. Легче ли работать с результирующим графом объектов (основанным на миксинах, а не на классах) с точки зрения обслуживания?

Answer 1

Ну, я использую Qi4j уже около года в проекте. Когда вы привыкнете к силе миксинов в своей доменной модели, вы будете удивляться, как раньше обходились без них. На самом деле, я считаю, что метод POJO для создания моделей предметной области должен быть устаревшим. Создает системно не поддерживаемый код. Поскольку смешанная / составная модель является важной особенностью Qi4j, а не DI, на платформе Java нет никакого сравнения.

Что касается опасений Божо: когда дело доходит до объявления миксинов, есть два отдельных случая. В сущностях, то есть в модели предметной области, интерфейс, как правило, имеет только одну реализацию, и вы на самом деле хотели бы активно избегать использования нескольких реализаций в целях обслуживания и удобочитаемости. Поэтому я объявляю реализацию прямо в интерфейсе. Но это только значение по умолчанию, которое может быть переопределено композитом, если вы хотите. Я до сих пор никогда не нашел в этом необходимости.

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

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

Answer 2

Kabram;Интеграция с JPA была предпринята несколько раз.Если у нас есть две частично совпадающие, но не полностью совместимые технологии, у вас останется только пересечение возможностей.Итак, есть два основных подхода к интеграции Qi4j с JPA.

1. Ограничить параметры JPA, чтобы в полной мере использовать гораздо более гибкие структуры данных, необходимые Qi4j.Делать это не имеет смысла, поскольку переход непосредственно к SQL гораздо более производительный, и это то, что мы выбрали.

2. Ограничить модель данных Qi4j для соответствия существующей модели данных JPA.Это лишит большинство преимуществ того, почему люди выбирают Qi4j в первую очередь.Поэтому мы решили не тратить на это циклы.Однако я думаю, что расширяемость Qi4j достаточно хороша для такой интеграции без взлома в Core Runtime и просто для создания EntityStore.

Answer 3

Надеюсь, не слишком поздно в этом обсуждении: Но вот как я это вижу.

Прежде всего мне нравятся идеи (композиты, миксины, сборки), лежащие в основе Qi4j, но меня сдерживает сложность его использования.

Концепции должны быть частью более широкого зонтика, такого как язык (например, Java), чем фреймворк, и должны быть более простыми в использовании.

Я столкнулся с проблемой 2 года назад, из-за чего мне было жаль, что у меня тогда не было такого.

Я хотел 3 разных поведения, которые можно было бы использовать на множестве бинов. Некоторые бобы использовали их все другие, любое сочетание двух. Я не хотел собирать их всех вместе в классе, потому что это не имело смысла. С другой стороны, я был ограничен тем фактом, что я не мог иметь множественное наследование. Очевидное решение: использовать интерфейс; что означает реализовать вещь, которая много раз. Я не забываю жаловаться коллеге на тот факт, что надеюсь, что у меня был способ обеспечить реализацию по умолчанию для интерфейса. Для меня это простая концепция ОО, которая позволяет более рационально использовать поведение. И если это тот случай, когда вам нужно что-то отличное от реализации по умолчанию, чем реализовать это. Это имело бы больше смысла и не нарушало бы никакого естественного закона, который я вижу.

Итак, чтобы ответить на ваш вопрос, я думаю, что концепции этого Qi4j позволяют вам мыслить ОО более чистым способом, где Spring более структурный и даже не сопоставим концептуально. Вы можете думать о инъекции зависимости, не думать весной и думать Qi4j, а не думать о глубокой инъекции.

Answer 4

Bozho; Для вас вопрос о объявлении Mixins на интерфейсах,

Реализации Mixin могут быть переопределены либо в «более высоких» (то есть под) интерфейсах, так как порядок поиска для реализаций происходит «для метода» и идет от объявленного интерфейса слева направо, а затем к каждому супер интерфейсов (также слева направо в предложении extends). ИЛИ, вы можете переопределить в сборке композита;

public void assemble( ModuleAssembly module )
{
    module.entities( Account.class ).withMixins( LdapAuthenticatorMixin.class );
    :
}

где LdapAuthenticatorMixin может быть абстрактным и перекрывать только один метод.

Answer 5

Когда я прочитал учебники по Qi4j за 2 минуты, 10 минут и т. Д. (Последний из них не завершен), возник один очевидный вопрос: как мне интегрировать это с управляемыми объектами JPA / Hibernate?Я хотел бы увидеть решение, которое легко интегрируется с JPA.По моему мнению, отсутствие JPA не означает принятия Qi4j.Мне бы очень хотелось увидеть статью автора (ов), в которой показана интеграция с JPA и Spring, двумя вещами, которые глубоко проникли в мир Java Enterprise.Если интеграция проста, быстрое принятие последует.

Answer 6

После прочтения первой части связанной статьи мне не понравились две вещи:

• реализации определены в интерфейсе (с использованием @Mixins) - что, если они должны быть посмешищемили реализации изменились?
• требует приведения

Не имея опыта работы с Qi4J, я не могу сказать, как это получается на практике, но это не очень хорошо.