php - example - symfony 4 restful




Guarde entidades en una API REST en lugar de DB utilizando Doctrine 2 (4)

Esto está relacionado con mi otra pregunta: entidades persistentes que usan una API REST .

Para un proyecto en Symfony2, necesito poder persistir entidades usando una API RESTful remota (de terceros) . También quiero poder recuperar entidades con datos de esa API.

En otras palabras, mis objetos se guardan en la base de datos de terceros . No se guardan en mi propia base de datos. Cada vez que necesito guardar datos o buscar datos, uso su API REST.

Me han señalado varias bibliotecas, incluida una hecha por Doctrine . Sin embargo, ninguno de ellos me ofrece lo que estoy buscando. El hecho por Doctrine es la mejor opción, pero usa el patrón Active Record y no ofrece todas las cosas dulces de Doctrine 2. No me malinterpreten, he estado usando implementaciones de Active Record durante mucho tiempo, pero ahora me he enamorado del patrón Data Mapper de Doctrine.

Idealmente, me gustaría poder usar el ORM de Doctrine y simplemente reemplazar la parte específica de la base de datos con la lógica que guarda entidades usando una llamada API. (y por supuesto los recupera usando esa misma API). De esta manera puedo guardar mis entidades usando aproximadamente la misma sintaxis:

// current way to save $entity in database:
$em = $this->getDoctrine()->getManager();
$em->persist($entity);
$em->flush();

// desired way to save $entity using REST API:
// (just an example, it doesn't have to be exactly like this)
$em = $this->getDoctrine()->getManager('rest');
$em->persist($entity);
$em->flush();

Tenga en cuenta que no estoy tratando de construir mi propia API, simplemente estoy tratando de comunicarme con una API de terceros para poder guardar mis entidades. Soy relativamente nuevo en Doctrine, pero me está gustando hasta ahora. Realmente me gusta la idea de separar la lógica de persistencia de las entidades, pero hasta ahora no puedo averiguar cómo puedo usar eso para guardarlas usando una API.

Hay un artículo en la documentación de Symfony que describe cómo trabajar con múltiples Administradores de Entidades . Estoy buscando una solución similar a esta, pero con un administrador de entidades que me permite usar REST en lugar de DB.

He intentado modificar el ORM de Doctrine, pero solo termino reescribiendo la mitad de su código porque (parece estar) muy unido a la lógica específica de la base de datos. Podría estar haciendo algo estúpido, por supuesto.

Entonces mi pregunta es, ¿hay alguna manera de reemplazar / anular las partes específicas de la base de datos de ORM de Doctrine con las personalizadas ? ¿Sin reescribir muchas cosas que deberían ser comunes para todos los métodos de persistencia? ¿Se ha hecho antes? ¿O simplemente no es posible porque Doctrine está destinado para su uso con una base de datos y no es lo suficientemente flexible para otros usos?

Mi propio progreso

CakePHP parece ser capaz de hacer esto, permitiéndole definir un DataSource personalizado. De esta manera puede guardar sus modelos usando una base de datos SQL, pero también usando una API, sesiones, etc. Quiero hacer más o menos lo mismo, pero usando Doctrine en lugar de CakePHP.

Actualización 1

Las consultas reales de la base de datos parecen ejecutarse por la clase Doctrine\ORM\Persisters\BasicEntityPersister . Hay varias otras clases xxxPersister, para tratar con diferentes tipos de herencia. Podría ser posible reemplazar las clases xxxPersister por las nuestras, de modo que podamos reemplazar el código DB con el código API REST.

Los objetos de persistencia se crean dentro del método getEntityPersister() de la clase Doctrine\ORM\UnitOfWork . Los nombres de clase están codificados, por lo que debemos anular Doctrine\ORM\UnitOfWork si queremos usar nuestros propios datos persistentes.

Actualización 2

Doctrine\ORM\UnitOfWork parece estar codificado en Doctrine\ORM\EntityManager , por lo que debemos reemplazarlo también. Sin embargo, esta clase parece contener algunas partes específicas de la base de datos. Por ejemplo, su constructor requiere un objeto Doctrine\DBAL\Connection como parámetro. Quizás sea mejor crear nuestro propio EntityManger (implementando la interfaz Doctrine\Common\Persistence\ObjectManager ), siempre que eso no tome demasiado tiempo / esfuerzo.

Actualización 3

El código específico de la base de datos para recuperar / cargar / encontrar objetos vive en la misma clase que el código para persistir / eliminar, etc.: las clases Doctrine\ORM\Persisters\xxxPersister . Entonces, si podemos reemplazarlos con los nuestros, para poder persistir en los objetos, también podemos recuperarlos. Cuando llame $entityRepository->findAll() , por ejemplo, devolverá $entityRepository->findBy(array()) (porque findAll() es simplemente un alias para findBy(array()) ) que ejecutará el siguiente código :

$persister = $this->_em->getUnitOfWork()->getEntityPersister($this->_entityName);

return $persister->loadAll($criteria, $orderBy, $limit, $offset);

En otras palabras, una vez que obtengamos EntityManager para crear los UnitOfWork adecuados UnitOfWork y xxxPersister , podremos usar los métodos find en el EntityRepository .

Actualización 4

Descubrí que se desarrolló una nueva función para Doctrine: persisters personalizados (también vea this ). Esto debería facilitar el uso de una clase de persistencia personalizada. Aún no sé si nos permitirá crear un servidor persistente no DB, pero parece prometedor. Sin embargo, las últimas actualizaciones fueron en agosto, así que no estoy seguro si todavía está en desarrollo activo.


Como una solución lista para usar no estaba disponible, decidí escribir la mía. Lo llamé RAPL . Está fuertemente inspirado en el ORM de Doctrine (de hecho, usa muchas de las interfaces proporcionadas por Doctrine Common).

Usando RAPL, puedo simplemente escribir un pequeño archivo YAML para configurar el mapeo entre mis entidades y el servicio web, lo que me permite persistir / recuperar entidades usando el EntityManager personalizado.


Creo que no estás en lo correcto.
No estoy listo para profundizar en la documentación ahora, pero entiendo doctrine stack como:

ORM -> DQL (lenguaje de consulta de doctrina) -> dbal -> Algunos SQL de base de datos

Y apunte a la implementación que presenta en DBAL como controlador de base de datos personalizado.

Creo que crear una característica interesante de REST-Driver es muy común y facilitará la integración con servicios de terceros.



Puede usar https://github.com/doctrine/rest para compilar un cliente REST, que se comunica con el servidor de destino. La parte esencial aquí es la asignación de la entidad (local) a la API REST (objetivo).

En resumen: Doctrine2 (DB local) -> Cliente de reposo (mapeo de entidad a reposo) -> Solicitud (servidor de destino)

Doctrine / Rest también proporciona al revés: un Doctrine Rest Server, para exponer sus entidades locales a través de REST (solicitudes a su servidor). Pero eso no es lo que estás buscando.







persistence