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

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

3 голосов
/ 08 сентября 2011

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

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

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(), чтобы игнорировать "отравленные" прокси-классы, но в этот момент мне кажется, что я слишком много борюсь с фреймворком ...

1 Ответ

3 голосов
/ 08 ноября 2011

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

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

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

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

  • RPC. Он не идеален для многих, но хорошо справляется со многими.
  • AutoBeans (на котором основывается RF) - все еще довольно быстрый и легкий способ отправлять данные по проводам и передавать их в приложение. Вы можете построить свою собственную оболочку вокруг нее, как это сделала RF, и уменьшить проблему, которую она пытается решить, до вашего варианта использования.
...