Возможно ли иметь POJO как ESuperType в EMF?

Вопрос/проблема

Учитывая простой класс Java, исходящий из API, не поддерживающего EMF, такого как

public class BankAccount {
    String ownerName;
    int accountNumber;

    // ...
}

а также предположим, что мне не разрешено изменять или перекомпилировать этот класс (потому что он из API).

Есть ли простой способ использовать этот класс в качестве ESuperType для EClass в EMF? (И, конечно, один класс - это просто пример. Мне нужно было бы обернуть API, состоящий из 30-50 классов...).

Собственные мысли

Лично я думаю, что это невозможно из коробки.

Я мог придумать только два способа, оба требуют значительных усилий и не так просты в реализации.

  1. Создайте модель Ecore, которая отражает исходный класс (EBankAccount, имеющий ownerName и accountNumber как EAttributes) и служебный метод/механизм, который заключает в себе исходный объект, копируя его поля в соответствующие EStructuralFeatures и добавляя EAdapter, отвечающие за синхронизацию обоих объектов.

  2. Подключитесь к EMF.CodeGen и сделайте там немного волшебства, которое позволит использовать исходный класс в качестве суперкласса в сгенерированном коде, который в то же время все еще выполняет контракт EMF (= реализовать интерфейс EObject и т. д.).

Но, может быть, есть какая-то скрытая функция EMF (или существующего расширения), которая делает что-то в этом роде, а я о ней не знаю?


person Stefan Winkler    schedule 21.07.2016    source источник


Ответы (1)


Мне непонятно, что вы на самом деле хотите, но я попытаюсь описать несколько вариантов.

Если вы хотите просто расширить POJO (что и предлагается в тексте вопроса), ответ будет ДА, вы можете просто добавить новый EClass в свою модель и сослаться на полное имя POJO в атрибуте «Имя типа экземпляра». Затем вы можете создать другие классы, которые расширяют этот класс, но EMF не будет управлять его состоянием.

Но если вы хотите, чтобы EMF отслеживал это состояние POJO, как если бы это был настоящий объект EMF (так что эти свойства также являются EStructuralFeature), тогда я не вижу другого решения, вам действительно нужно полностью смоделировать его в EMF.

Во втором случае возможны оба описанных вами варианта.

  1. Первый вариант, который вы описали (и я предполагаю, что вы имеете в виду, что хотите синхронизировать 2 объекта, а не 2 класса), кажется самым простым, и я не думаю, что потребуется так много усилий, если вы используете какой-то общий метод через отражение .
    Это может быть хорошим решением, если вы получаете объекты в очень конкретных местах, поэтому вам нужно обернуть и развернуть только в определенных местах. В противном случае вам нужно будет постоянно преобразовывать (обертывать/разворачивать) объект.

  2. Это также возможно, но требует больше усилий, так как расширять шаблоны Java JET непросто.

Я не знаю никакого расширения для этого.

person xsilmarx    schedule 22.07.2016
comment
+1 для атрибута имени типа экземпляра. Я никогда не использовал его. Я поиграю с ним и посмотрю, что он делает... - person Stefan Winkler; 22.07.2016