任何使用qi4j的人

嗯,我在一个项目中使用qi4j已经一年了。一旦你习惯了域模型中混音器的强大功能,你就会想知道你以前是如何在没有混音器的情况下进行管理的。实际上,我认为创建域模型的POJO方法应该是过时的。它创建了系统上无法维护的代码。因为MIXIN/复合模型是Qi4J的重要特征,而不是DI,所以Java平台上没有任何的比较。

至于博日的担忧:在声明mixin时,有两个独立的案例。在实体(即域模型)中,一个接口通常只有一个实现,实际上,出于维护和可读性的原因,您希望主动避免有多个实现。所以我直接在接口中声明实现。但是,它只是一个默认值,如果您愿意的话,它可以被组合覆盖。到目前为止,我还没有找到这样做的必要。

另一种情况是服务,这是非常不同的。在许多情况下,只有一个实现,因此在接口中声明该实现还是可以的。但是,对于需要不同实现的服务,有更多的情况,因此对于这些情况,您只需在具体的复合类型声明中声明mixin。因此,这两种样式都是可能的,出于各种原因推荐使用。

至于铸造,能够铸造一个对象是一个奖金,而不是一个问题。如果您没有从一个角色到另一个角色的角色转换,那么您必须非常有创造力才能绕过它,这可能不会使您的代码更简单。

多次尝试与JPA集成。如果我们有两个重叠但不完全兼容的技术,那么您最终只会遇到可能性的交叉点。因此,有两种基本方法可以将qi4j与jpa集成在一起。

1. 为了限制JPA选项,以便可以充分使用QI4J需要的更灵活的数据结构。这样做毫无意义,因为直接访问SQL更具性能,这是我们选择的。

2. 限制qi4j的数据模型以适合现有的JPA数据模型。这样做将从一开始就剥夺人们选择qi4j的大部分优势。因此,我们决定不花时间来做这件事。但是,我认为qi4j的可扩展性足以在核心运行时不进行黑客攻击的情况下进行这种集成,并且只创建一个EntityStore。

希望这次讨论不要太晚: 但我就是这样看的。

首先,我喜欢qi4j背后的想法(复合、混合、组装),但是由于使用它的复杂性,我被抑制了。

概念应该是更广泛的伞的一部分,如语言(如Java)而不是框架,并且应该更容易使用。

两年前我遇到了一个问题,那让我希望我当时有这样的事情。

我想要3种不同的行为,可以在一组bean上重用。有些豆子把它们都用了,其他的则是二者的任意组合。我不想把他们都放在一起上课,因为这不合理。另一方面,我被这样一个事实所约束:我不能有多重继承。显而易见的解决方案是:使用一个接口;这意味着要实现很多次。 我记得我曾向同事抱怨过这样一个事实:我希望我有一种方法可以为接口提供默认的实现。对我来说,这是一个简单的OO概念,它允许人们以更干净的方式重用行为。如果是这样的话,你需要一些不同于默认实现的东西来实现它。这将更有意义,不会破坏我所能看到的任何自然法则。

因此,为了回答你的问题,我认为qi4j的概念允许你以更干净的方式来思考oo,在这里,春天更具结构性,甚至在概念上无法比较。你可能在想依赖注入,而不是在想春天,在想qi4j,而不是在想部门注入。

在阅读了链接文章的第一部分后,我不喜欢两件事:

• 实现在接口中定义(使用 @Mixins )-如果这些应该被模拟,或者实现发生了变化怎么办?
• 需要铸造

由于我对Qi4J没有经验,我不能说这在实践中是如何发生的,但感觉不太好。

当我在2分钟、10分钟等时间内阅读了qi4j教程(最后一个教程不完整)时,我想到的一个显而易见的问题是如何将其与jpa/hibernate管理的实体集成?我希望看到一个与JPA无缝集成的解决方案。在我看来,没有JPA意味着没有QI4J的采用。我想看到作者(s)的一篇文章,展示了与JPA和Spring的集成,这两个东西在Java企业界有着深刻的渗透。如果集成是直接的,那么将随后快速采用。

对于您来说,关于接口上声明的mixin的问题,

mixin实现可以在“更高”(即子)接口中被重写,因为实现的查找顺序是“按方法”发生的,从声明的接口向左向右,然后到每个超级接口(在extends子句中也是从左向右)。或者,可以在组合的组合中重写;

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

其中,ldapauthenticatormixin可能是抽象的,并且只重写一个方法。