Могу ли я использовать RequestFactory без методов getId() и getVersion()?

Мы пытаемся использовать RequestFactory с существующей моделью объекта Java. Все наши объекты Java реализуют интерфейс DomainObject и предоставляют метод getObjectId() (это имя было выбрано, поскольку getId() может быть двусмысленным и конфликтовать с фактическим идентификатором объекта домена из моделируемого домена.

Интерфейс ServiceLayerDecorator позволяет настраивать стратегии поиска свойств ID и версии.

public class MyServiceLayerDecorator extends ServiceLayerDecorator {
    @Override
    public Object getId(Object object) {
        DomainObject domainObject = (DomainObject) object;
        return domainObject.getObjectId();
    }
}

Все идет нормально. Однако попытка развернуть это решение приводит к ошибкам времени выполнения. В частности, RequestFactoryInterfaceValidator жалуется:

[ERROR] There is no getId() method in type com.mycompany.server.MyEntity

Затем позже:

[ERROR] Type type com.mycompany.client.MyEntityProxy was previously marked as bad
[ERROR] The type com.mycompany.client.MyEntityProxy did not pass RequestFactory validation
[ERROR] Unexpected error
com.google.web.bindery.requestfactory.server.UnexpectedException: The type com.mycompany.client.MyEntityProxy did not pass RequestFactory validation
    at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.die(ServiceLayerDecorator.java:212) ~[gwt-servlet.jar:na]

Мой вопрос: почему ServiceLayerDecorator позволяет настраивать стратегии поиска идентификатора и версии, если RequestFactoryInterfaceValidator жестко кодирует соглашение getId() и getVersion()?

Думаю, я мог бы переопределить ServiceLayerDecorator.resolveClass(), чтобы игнорировать "отравленные" прокси-классы, но на данный момент кажется, что я слишком много борюсь с фреймворком...


gwt requestfactory
person Eric    schedule 07.09.2011    source источник
comment
После копания в RequestFactoryInterfaceValidator и повторного чтения документов мне кажется, что мне может понадобиться использовать здесь собственный тип Locator...   -  person Eric    schedule 08.09.2011
comment
Однако применяется более фундаментальный вопрос. Какой смысл разрешать глобальное переопределение getId() и getVersion() в ServiceLayerDecorator, если мне все еще нужно пометить каждый EntityProxy определенным Locator, который также определяет это поведение?   -  person Eric    schedule 08.09.2011

Ответы (1)


arrow_upward
3
arrow_downward

Несколько вариантов, некоторые из которых уже упоминались:

  • Locator. Мне нравится создавать единый локатор для всего проекта или, по крайней мере, для групп связанных объектов с похожими типами ключей. Вызов getId() сможет вызвать ваш метод DomainObject.getObjectId() и вернуть это значение. Обратите внимание, что метод getDomainType() в настоящее время не используется и может возвращать значение null или вызывать исключение.
  • ValueProxy. Вместо того, чтобы сопоставлять ваши объекты с чем-то, что RF может понять как сущность, сопоставьте их с объектами с простыми значениями - идентификатор или версия не требуются. RF упускает много умных вещей, которые он может сделать, особенно в отношении предотвращения отправки избыточных данных на сервер.
  • ServiceLayerDecorator. Это работало до версии 2.4, но с обработкой аннотаций, которая продолжается сейчас, работает хуже, так как пытается сделать часть работы за вас. Кажется, ServiceLayerDecorator потерял много своих зубов за последние несколько месяцев — теоретически вы могли бы использовать его для перестройки геттеров, чтобы они напрямую взаимодействовали с вашим механизмом персистентности, но теперь, когда обработка аннотаций проверяет ваш код, это больше не вариант. .

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

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

  • РПЦ. Он не идеален для многих задач, но для многих он работает нормально.
  • AutoBeans (на котором основан RF) по-прежнему является довольно быстрым и легким способом отправки данных по сети и передачи их в приложение. Вы можете создать свою собственную оболочку вокруг него, как это сделал RF, и сократить проблему, которую он пытается решить, до вашего варианта использования.
person Colin Alworth    schedule 08.11.2011