Воспроизведение объектов модели из внешнего API - программирование
Подтвердить что ты не робот

Воспроизведение объектов модели из внешнего API

Я новичок в Play 2 Framework v. 2.1.1 с Java, и я ищу лучший способ сделать следующее без дублирования кода.

Чтобы упростить, у меня есть backoffice Play 2, в котором используется внешний API. Я не управляю этим API, но я вызываю REST Services для выполнения операций над api.

Эти объекты API полностью совпадают с объектами модели Play 2. Но я не хочу дублировать объекты api, чтобы добавить проверки воспроизведения и другие аннотации.

Есть ли способ добавить этот тип поведения с помощью файлов конфигурации? Я думаю о чем-то вроде Hibernate hbm, например.

Например:

Объект в неуправляемом api: (я просто опускаю геттеры и сеттеры)

public class Entity{
    public String field1;
    public String field2;
}

Объект, который я хочу избежать: (я просто опускаю геттеры и сеттеры)

public class Entity1{

    @Required
    @NonEmpty
    @MinLength(3)
    public String field1;

    @Required
    @NonEmpty
    public String field2;
}

Пример конфигурации: (мне нужно что-то вроде этого)

<class name="Entity1">
    <property name="field1" >
        <required/>
        <nonEmpty/>
        <minLength value="3"/>
    </property>
    <property name="field2" >
        <required/>
        <nonEmpty/>
    </property>
</class>

Использование аннотаций кажется лучше, чем использование xmls или любого другого файла конфигурации, поэтому я не обязательно хочу использовать файлы конфигурации, я открыт для любых предложений по решению этой проблемы.

Спасибо

4b9b3361

Ответ 1

Я не вижу, как дублирование модели API в нестандартном дескрипторе, таком как XML, лучше, чем использование языка типов. Более того, я бы не хотел связывать свою модель и приложение с моделью из API под моим контролем.

Я думаю, что гораздо лучше дублировать модель в Java/ Scala и использовать простой копир bean, например, для перемещения между ними.

Ответ 2

Одной из проблем является ebean в качестве поставщика персистентности - в ebean нет способа экстренной настройки конфигурации сохранения bean, как это возможно в спящем режиме (за исключением sql-запросов). Возможно ли использование коммутатора поставщика непрерывности? Игра, похоже, позволяет это.

Поскольку вы написали, что не можете изменить исходный код сущностей, и вы не хотите копировать источник, единственная возможная возможность, которую я вижу, - это улучшение байт-кода.

Вам нужна библиотека, которая позволит вам экртизовать аннотации в XML файле. В этой библиотеке будет использоваться аппликация api, прочитайте xml файл в jvm statup и измените байт-код каждого перечисленного класса, чтобы добавить аннотации к классу и полям во время выполнения.

Существуют две проблемы с этим подходом:

  • Нет такой библиотеки (по крайней мере, я не мог ее найти)
  • Play и EBean используют собственный агент/загрузчик классов, чтобы обеспечить горячее развертывание и сохранение.

Первая проблема - легкая и интересная часть, см., например, https://today.java.net/pub/a/today/2008/04/24/add-logging-at-class-load-time-with-instrumentation.html. С javaassist легко добавлять аннотации к классам и полям. Отображение из xml в аннотации является прямым. И это был бы хороший проект с открытым исходным кодом.

Вторая проблема выглядит намного сложнее, потому что вы должны установить свой агент аннотации, чтобы он выполнялся до начала игры, а ebean начал разбирать аннотации.

Ответ 3

Мне непонятно, почему нельзя добавлять аннотации в собственное приложение, но если у вас есть такие ограничения, почему бы вам просто не расширить класс, переопределить переменные, добавить аннотации и использовать их как EBean модель?

Ответ 4

Воспроизведение имеет динамические формы, которые позволяют вам проверять сопоставление пары ключей, значений. Если валидация - это то, что вы хотите, вы можете скопировать данные сущности на карту и подтвердить это.

Ответ 5

Простой ответ: не всегда повторяется дублирование кода, если строки кода одинаковы.

Роберт К. Мартин показывает это в одном из своих разговоров: единственный ответственный принцип. Есть два способа разбить этот принцип: с одной стороны, две обязанности в одном фрагменте кода, с другой стороны, одна ответственность обрабатывается независимо друг от друга двумя фрагментами кода.

Дублирование кода - это вопрос ответственности и семантики не кодовых строк, которые являются одинаковыми (что может быть не более чем показателем для дублирования кода).

В вашем случае обязанности четко разделены: у вас есть внешний API и ваш код. Таким образом, дублирование кода отсутствует.