Symfony2 Entity opslaan door middel van REST API
Ik heb enkele dagen geleden een vraag op Stack Overflow gesteld, maar nog geen antwoord gekregen dat voldoet aan waar ik naar op zoek ben. Klik hier voor de betreffende vraag op Stack Overflow.
In het kort komt het erop neer dat ik een aantal Entity's niet wil opslaan in de database (met behulp van Doctrine) maar door middel van een HTTP-verzoek naar een externe API. De API zal de gegevens opslaan zodat ik ze later ook weer kan opvragen (en de Entity ermee kan vullen).
Ik ben op zoek naar bij voorkeur een kant-en-klare oplossing die ik simpelweg aan mijn composer-bestand kan toevoegen en er vervolgens gelijk mee aan de slag kan.
Als ik de OOP-principes goed heb begrepen dan dient de Entity zelf niet te weten hoe hij wordt opgeslagen. Een Active Record-oplossing, zoals DREST van Doctrine is dus niet wat ik zoek. Op Stack Overflow werd ook een ander project (ook met de naam DREST) gesuggereerd, dat gaat al meer de juiste kant op.
Zijn er op dit forum ook Symfony-gebruikers aanwezig die dit al eens eerder hebben gedaan en mij kunnen vertellen hoe ze het hebben opgelost?
Alvast bedankt!
Ondertussen ben ik tot de conclusie gekomen dat het wenselijk is om met Doctrine te werken, en Doctrine zodanig te extenden dat mijn data wordt opgeslagen middels een REST APIDoctrine zodanig te extenden dat mijn data wordt opgeslagen middels een REST API in plaats van mijn eigen database.
Ik ben maar begonnen met handmatig de code van Doctrine uit te pluizen in de hoop dat ik hier en daar een class kan vervangen met een class die door mijzelf is geschreven. Mocht iemand hier ervaring mee hebben dan hoor ik het natuurlijk graag.
Het doel is dat ik uiteindelijk de Entity Manager en Entity Repository van Doctrine kan gebruiken, maar dat 'onder de motorkap' een andere methode van opslaan en ophalen van data wordt toegepast.
Klik, voor het topic op Stack Overflow, op bovenstaande link. (dit is overigens een andere vraag dan waar ik in mijn vorige link naar verwees)
Gewijzigd op 13/12/2013 14:08:06 door Nic W
Wat je eigenlijk gewoon moet doen is kijken naar doctrine/commons. Deze bevat de interfaces/classes die de bekende doctrine API kenmerken. Die gebruik jij dan om jouw eigen storage layer te maken.
Het lijkt mij zelf allemaal veel te omslachtig. Waarom wil je per se de Doctrine API gebruiken en niet je eigen, veel simpelere, API?
Wouter J op 13/12/2013 15:43:28:
Doctrine code bekijken, slechte keuze :) Het is een van de vreselijkste broncodes die ik heb gezien :D
Hahaha, is dat zo? Wat is er zo slecht aan dan?
Wouter J op 13/12/2013 15:43:28:
Wat je eigenlijk gewoon moet doen is kijken naar doctrine/commons. Deze bevat de interfaces/classes die de bekende doctrine API kenmerken. Die gebruik jij dan om jouw eigen storage layer te maken.
Het lijkt mij zelf allemaal veel te omslachtig. Waarom wil je per se de Doctrine API gebruiken en niet je eigen, veel simpelere, API?
Het lijkt mij zelf allemaal veel te omslachtig. Waarom wil je per se de Doctrine API gebruiken en niet je eigen, veel simpelere, API?
Misschien maak ik het mezelf inderdaad een beetje te moeilijk. Maar ik kon nergens een goede oplossing vinden om mijn entities op deze manier op te slaan. (alleen een library van Doctrine zelf, maar die gebruikt het Active Record patroon en ik geloof dat het juist beter is als een Entity niet weet hoe hij wordt opgeslagen)
Als ik dan toch zelf iets ga knutselen, dan leek het me handig om dat te baseren op Doctrine 2 zodat ik (hopelijk) een hoop features (die niet per se database-specifiek zijn) kan herbruiken. Én als extra voordeel kan ik dan grotendeels dezelfde syntax gebruiken: $em->persist($entity); etc.
Maar, het zal ongetwijfeld niet zo makkelijk gaan als dat ik nu denk...
-Edit-
Mijn achterliggende gedachte was ook, dat het heel makkelijk zou zijn om een entity die in de database wordt opgeslagen, voortaan via de REST API op te slaan. Simpelweg een nieuw YAML bestand voor de mapping toevoegen, een andere EntityManager gebruiken en klaar is Kees.
Gewijzigd op 13/12/2013 17:02:39 door Nic W
Quote:
Doctrine code bekijken, slechte keuze :) Het is een van de vreselijkste broncodes die ik heb gezien :D
@Wouter, waarom vind je de broncode van Doctrine slecht?
Doctrine is voor data access mbt een database, evenals de entitymanager van Doctrine, wanneer je data ophaalt van een api, en deze niet oplaat in een database, zal je een nieuwe entitymanager moeten maken die wel kan communiceren met een api.
Gewijzigd op 14/12/2013 00:38:09 door Local Dev