Любой, кто использует Qi4J

Ответ 1

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

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

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

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

Ответ 2

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

• Чтобы ограничить параметры JPA, чтобы можно было использовать полностью более гибкие структуры данных, которые Qi4j. Выполнение этого не имеет смысла, поскольку переход непосредственно к SQL намного более эффективен, и именно это мы и выбрали.

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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