EMFでPOUOをESuperTypeにすることは可能ですか？単純なJavaクラスは、このような</p> <pre><code>public class BankAccount { String ownerName; int accountNumber; // ... } </code></pre> <p>などの非EMF対応のAPIから来るとものは、私は（このクラスを変更したり、再コンパイルすることは許されないのですと仮定しましょう考える

Question

質問/問題

これはAPIからのものです）。

このクラスをEMFのEClassのESuperTypeとして使用する簡単な方法はありますか？ （そして、もちろん、単一のクラスは単なる例です。私は30-50クラスからなるAPIをラップする必要があります...）。

自身の考え

は個人的に、私はそれが箱の外には不可能だと思います。

私は2つの方法しか考えられませんでしたが、どちらもかなり努力して実現するのは簡単ではありません。

1. （EAttributesとしてownerNameとaccountNumberを有する、EBankAccount）元のクラスを反映したEcoreモデルと対応EStructuralFeaturesにそのフィールドをコピーし、元のオブジェクトをラップし、ユーティリティ方法/機構を作成するには、EAdapter Sを付加します両方のオブジェクトを同期させる責任があります。

2. EMF契約書（= EObjectインターフェースなどを実装しています）と同時に、生成コードに元のクラスを持つことができるように、EMF.CodeGenにフックして、 。

しかし、EMF（または既存の拡張機能）の隠れた機能がありますが、これらの行には何かがありますが、わからないのですか？

Answer 1

あなたが本当に望むものは私には分かりませんが、いくつかのオプションについて説明します。

POJO（質問テキストの示唆）を拡張するだけの場合は、答えはYESです。モデルに新しいEClassを追加し、POJO修飾名を "インスタンスタイプ名"属性。次に、このクラスから拡張する他のクラスを作成できますが、その状態はEMFによって管理されません。

EMFが実際のEMFオブジェクトのようにそのPOJO状態を追跡するようにしたい場合（これらのプロパティもEStructuralFeatureです）、別のソリューションは表示されません。実際にEMFで完全にモデル化する必要があります。

この2番目のケースでは、説明した両方のオプションが可能であるようです。

1. あなたが説明した最初のオプションは、最も簡単な1ようだ（と私はあなたが2つのオブジェクトではなく、2クラスを同期する意味と仮定）、と私はそれがそんなに手間がかかるだろうとは思いませんリフレクションでいくつかの一般的なメソッドを使用する場合。
   非常に具体的な場所にオブジェクトを置くと良い解決策になるので、特定の場所でラップして展開するだけです。それ以外の場合は、オブジェクトを常に変換（ラップ/アンラッピング）する必要があります。

2. ことも可能かもしれないが、それは

のJava JETテンプレートを拡張することは容易ではありませんので、私はこのために任意の拡張子を認識していないよ、確かに多くの努力が必要です。