2016-07-21 14 views
0

질문/문제EMF에서 POUO를 ESuperType으로 사용할 수 있습니까?

비 EMF 인식 API에서 오는 일반 자바 클래스 감안할 때 같은

public class BankAccount { 
    String ownerName; 
    int accountNumber; 

    // ... 
} 

또한이의 내가 변경하거나 (이 클래스를 재 컴파일 할 수 없습니다하고 있다고 가정하자 그것은 API에서 온 것이기 때문에).

이 클래스를 EMF의 EClass에 대한 ESuperType으로 사용하는 간단한 방법이 있습니까? (그리고 물론, 단일 클래스는 단지 예일뿐입니다. 30-50 클래스로 구성된 API를 랩핑해야합니다 ...).

자신의 생각

는 개인적으로, 나는 그것이 상자 밖으로 불가능하다 생각합니다.

저는 두 가지 방법 만 생각할 수 있습니다. 두 가지 방법 모두 상당한 노력과 실현이 쉽지 않습니다.

  1. (EAttributes 같은 ownerNameaccountNumber을 갖는 EBankAccount) 원래 클래스를 반영한는 Ecore 모델과 대응 EStructuralFeatures으로 해당 필드를 복사하여 원래 객체를 포함하고있는 유틸리티 방법/메커니즘을 만들기 EAdapter들 더하는 두 개체를 동기화 할 책임이 있습니다.

  2. EMF 계약서 (= EObject 인터페이스 등 구현)와 동시에 생성 된 코드에서 원본 클래스를 EMF.CodeGen에 수퍼 클래스로 만들 수있는 마법을 수행합니다. .

하지만 어쩌면이 EMF의 일부 숨겨진 기능 (또는 기존의 확장)이 라인을 따라 무언가를, 그리고 나는 그것을 인식하지입니까?

답변

3

내가 원하는 것이 무엇인지 분명하지 않지만 몇 가지 옵션을 설명하려고합니다.

질문 텍스트에서 제시 한대로 POJO를 확장하려면 대답은 YES입니다. 모델에 새 EClass를 추가하고 "인스턴스 유형 이름"에서 POJO 정규화 된 이름을 참조하기 만하면됩니다 "속성. 그런 다음이 클래스에서 확장되는 다른 클래스를 만들 수 있지만 EMF가 해당 클래스의 상태를 관리하지는 않습니다.

EMF에서 실제 EMF 객체 인 것처럼 POJO 상태를 추적하려면 (그 속성도 EStructuralFeature이므로) 다른 해결책은 보이지 않습니다. EMF에서 완전히 모델링해야합니다.

두 번째 경우에 설명 된 두 옵션 모두 가능합니다.

  1. 당신이 설명하는 첫 번째 옵션은 가장 쉬운 것 (그리고 나는 당신이이 객체가 아닌이 개 클래스를 동기화 할 말은 가정), 나는 너무 많은 노력이 걸릴 것이라고 생각하지 않는다 리플렉션을 통해 일반적인 방법을 사용하는 경우
    매우 구체적인 위치에 개체를 가져 오는 경우이 방법이 좋은 해결책 일 수 있으므로 특정 위치 만 포장하고 풀어야합니다. 그렇지 않으면 항상 오브젝트를 변환 (랩핑/언 래핑)해야합니다.

  2. 또한 가능할 수도 있지만 나는이에 대한 확장 잘 모르는 것 같아요 자바 JET 템플릿

을 확장하는 것은 쉽지 않다 이후는, 확실히 더 많은 노력이 필요합니다.

+0

+1 "인스턴스 유형 이름"속성. 나는 그것을 사용한 적이 없다. 나는 그걸 가지고 놀고 그것이하는 일을 보게 될 것이다 ... –