2016-07-21 27 views
0

问题/问题是否有可能在EMF中拥有ESuperType的POJO?

给出一个简单的Java类与非EMF感知API来如

public class BankAccount { 
    String ownerName; 
    int accountNumber; 

    // ... 
} 

,也让我们假设我不允许更改或重新编译这个类(因为它来自API)。

是否有任何简单的方法可以将此类用作EMF中的EClass的ESuperType? (当然,单个类只是一个例子,我需要包装一个由30-50个类组成的API ...)。

自己的想法

就个人而言,我认为这是不可能的开箱。

我只能想到两种方式,都有相当的努力,不容易实现。

  1. 创建反映原类(EBankAccount,具有ownerNameaccountNumber作为EAttributes)Ecore模型和公用方法/机制,通过复制其字段到对应EStructuralFeatures包装了原始对象,并将EAdapter S的负责同步两个对象。

  2. 挂钩到EMF.CodeGen中,并在那里做一些魔术,这样就可以在生成的代码中使原始类作为超类,同时仍然实现EMF合约(=实现接口等) 。

但也许有一些EMF(或现有的扩展)隐藏功能,沿着这些线做一些事情,我不知道它?

回答

3

我不清楚你真正想要什么,但我会尝试描述几种选择。

如果您只想扩展POJO(这是问题文本的建议),则答案为YES,您可以简单地向模型添加新的EClass,并在“实例类型名称”中引用POJO限定名称“属性。然后你可以创建其他的类,但是它的状态不会被EMF管理。

但是,如果您希望EMF跟踪该POJO状态,就好像它是一个真正的EMF对象(因此这些属性也是EStructuralFeature),那么我看不到另一个解决方案,您真的需要在EMF中完全建模。

在这第二种情况下,您描述的两个选项似乎都是可能的。

  1. 您所描述的第一个选项(我假设你的意思是你要的2个对象,而不是2类同步)似乎是最容易的,我不认为它会采取这么多的努力如果你通过反射使用一些通用的方法。
    如果您在非常具体的位置获得物体,这可能是一个很好的解决方案,因此您只需要在特定位置打包和解包。否则,你将需要转换转换(包装/解包)对象。

  2. 这可能是也可能的,但它需要更多的努力是肯定的,因为它不容易扩展Java JET模板

我不知道任何扩展这一点。

+0

+1为“实例类型名称”属性。我从来没有用过它。我会玩弄它,看看它有什么... –

相关问题