¿Puedo usar los métodos de requestFactory sin getId () y getVersion ()?

Question

Estamos tratando de usar RequestFactory con un modelo de entidad Java existente. Nuestras entidades Java implementan un DomainObject interfaz y exponer un getObjectId() Método (este nombre fue elegido como getId() puede ser ambiguo y en conflicto con el objeto de dominio actual ID del dominio que está siendo modelado.

los ServiceLayerDecorator La interfaz permite la personalización de las estrategias de búsqueda de propiedades de identificación y versión.

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

Hasta aquí todo bien. Sin embargo, tratar de implementar esta solución produce errores de tiempo de ejecución. En particular, RequestFactoryInterfaceValidator se queja:

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

Luego más tarde:

[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]

Mi pregunta es: ¿por qué el ServiceLayerDecorator Permitir estrategias de búsqueda de ID y versión personalizadas si RequestFactoryInterfaceValidator está codificando la convención de getId() y getVersion()?

Supongo que podría anular ServiceLayerDecorator.resolveClass() para ignorar las clases de poder "envenenadas", pero en este punto parece que estoy luchando demasiado en el marco ...

Answer 1

Un par de opciones, algunas de las cuales ya se han mencionado:

• Locator. Me gusta hacer un solo localizador para todo el proyecto, o al menos para grupos de objetos relacionados que tienen tipos clave similares. La llamada getId () podrá invocar su método domainObject.getObjectId () y devolver ese valor. Tenga en cuenta que el getDomainType() El método actualmente no se usa y puede devolver nulo o lanzar una excepción.
• ValueProxy. En lugar de que sus objetos se asignen a algo que RF puede entender como una entidad, asigna a objetos de valor simple, no se requiere ID ni versión. RF pierde muchas cosas inteligentes que puede hacer, especialmente con respecto a evitar el envío de datos redundantes al servidor.
• ServiceLayerDecorator. Esto funcionó antes de 2.4, pero con el procesamiento de anotación que continúa ahora, funciona menos bien, ya que trata de hacer algo de trabajo por usted. Parece que ServiceLayerDecorator ha perdido muchos de sus dientes en los últimos meses; en teoría, podría usarlo para reconstruir a los obtentadores para hablar directamente con su mecanismo de persistencia, pero ahora que el procesamiento de anotaciones verifica su código, esa no es una opción más opción .

El gran problema en todo esto es que SolicFactory está diseñado para resolver un solo problema y resolverlo bien: permita que los desarrolladores usen POJOS asignados a algún mecanismo de persistencia y consulte a esos objetos del cliente, siguiendo ciertas convenciones para evitar escribir código adicional o configuración.

Como resultado, resuelve su propio problema bastante bien y termina siendo un mal ajuste para muchos otros problemas/casos de uso. Puede estar descubriendo que no vale la pena: si es así, algunos pensamientos que podría considerar:

• RPC. No es perfecto para mucho, pero hace un buen trabajo por mucho.
• Los Autobeans (en los que se basa RF) sigue siendo una forma bastante rápida y liviana de enviar datos a través del cable y llevarlos a la aplicación. Puede construir su propio envoltorio a su alrededor, como lo ha hecho RF, y adelgazar el problema que está tratando de resolver solo para su caso de uso.