1

Java で EMF フレームワークを使用していくつかのコードに取り組んでいますが、非常に使いにくいです。たとえば、タイプ セーフな EMF の上に OCL のようなクエリ API を実装することはできません。

理由の 1 つは、eGet()aがではなくのみをEStructuralFeature返すことです。したがって、私が書くものはすべて、安全ではなく、パフォーマンスが悪く、再利用可能な方法で一般化できない null チェック、型チェック、および型キャストの多くを使用する必要があります。ObjectEObject

EObjectEMFが任意のObject値のラッパーでダミーの実装を生成しないのはなぜですか?

単純なスローであってもEObject、インターフェイスを実装するのは本当に面倒です (API が大きすぎます)。同じことが、モデルを上に移動するのが苦痛になる方法にも当てはまります。EClassUnsupportedOperationExceptioneContainer()

4

2 に答える 2

3

同じメソッドを使用して単純な属性値 (任意の Java タイプ) にアクセスし、モデル化された他のオブジェクトへの関係をトラバースします。

EMF は、オブジェクトが EClass のインスタンスであるかどうか、または EClass が別のオブジェクトに割り当て可能かどうかをチェックするための一般的なメカニズムを提供するので、私はそれに関する問題を実際には見ていません。

于 2010-03-30T04:00:55.207 に答える
1

eGet（）メソッドはEMFリフレクティブAPIの一部です。EMFはシリアル化可能なオブジェクトをラップできるため、そのようなリフレクティブAPIの返されるオブジェクトを制限することはできません。

ecoreモデルの生成されたJava実装の代わりに、このリフレクティブAPIを使用する必要があるのはなぜですか？このようにして、ドメインオブジェクトを操作するためのすべての直接適切に型指定されたAPIを使用できます。

于 2011-05-11T11:39:26.817 に答える