Implementatie vervangen als gebruiker ingelogd is

[TheNephilim]

Is het heel vreemd om te implementatie van de winkelwagen te vervangen als een gebruiker ingelogd is?

Voor 'gasten' worden items in de winkelwagen opgeslagen in de sessie, terwijl voor ingelogde gebruikers de items worden opgeslagen in de database. Dus ik heb een interface die voorschrijft wat een implementatie allemaal moet kunnen en dus twee implementaties.

Nu wil ik in de service provider eigenlijk zeggen; als de gebruiker ingelogd is, geef database-implementatie terug en anders de sessie-implementatie.

[Hydra]

Kan. Maar als een gebruiker alsnog inlogt wil je volgens mij dat 'ie z'n winkelmand houdt. Dus lijkt 't me logischer beiden in de DB te doen en gewoon 'tijdelijke' users te maken.

[NMe]

Ik heb het altijd beide in de database gezet, ingelogd of niet. ID van het winkelwagentje vervolgens in de sessie zetten, niet de hele winkelmand zelf. Voordeel: je hebt maar één implementatie die altijd werkt en hoeft bij het inloggen eigenlijk alleen maar "orphaned" winkelwagentjes (zonder user-ID dus) die via de sessie doorgegeven worden even aan de gebruiker toe te voegen (lees: user-ID bij in het winkelwagentje updaten).

[ Voor 12% gewijzigd door NMe op 19-06-2018 17:24 ]

[RobIII]

Hydra schreef op dinsdag 19 juni 2018 @ 17:16:
Dus lijkt 't me logischer beiden in de DB te doen en gewoon 'tijdelijke' users te maken.

Dat, of bij inloggen 't zwikkie 'overhevelen' (maar granted, dat is waarschijnlijk meer werk). Dus ik sluit me wel aan bij je (en @NMe )

[ Voor 7% gewijzigd door RobIII op 19-06-2018 17:20 ]

[Hydra]

NMe schreef op dinsdag 19 juni 2018 @ 17:19:
Ik heb het altijd beide in de database gezet, ingelogd of niet. ID vervolgens in de sessie zetten, niet de hele winkelmand zelf. Voordeel: je hebt maar één implementatie die altijd werkt en hoeft bij het inloggen eigenlijk alleen maar "orphaned" winkelwagentjes die via de sessie doorgegeven worden even aan de gebruiker toe te voegen.

Komt ook nog eens bij dat als je meer dan 1 applicatieserver hebt je sessies toch via een database moet delen dus dan heb je het alsnog in een DB zitten.

[RobIII]

Hydra schreef op dinsdag 19 juni 2018 @ 17:22:
Komt ook nog eens bij dat als je meer dan 1 applicatieserver hebt je sessies toch via een database moet delen dus dan heb je het alsnog in een DB zitten.

offtopic:
Dat vind ik wel een vrij korte redenering: meer dan 1 appserver dus database. Ik heb het gezien met memcaches, sticky sessions in loadbalancers, IIS heeft (meen ik?) een proprietary technologietje hiervoor (StateServer? Of draait dat op een RDBMS?), dan heb je nog de "client side" tokens (JWT of hoe heet het vandaag?) en dan heb je idd ook nog de databases (RDBM'ses t/m de NoSQL's en andere hippe termen. Maar again, je bewering is grofweg en meestal idd een veilige aanname. Eensch. Wou alleen even wat nuanceren

[ Voor 9% gewijzigd door RobIII op 19-06-2018 17:36 ]

[TheNephilim]

Duidelijk! Gewoon beide in de database gooien dus.

Het toewijzen van de winkelwagen bij inloggen is dan het makkelijkst denk ik. Voordeel is ook dat er nog wat te analyseren valt aan de winkelwagens die 'abandoned' zijn.

Danku!

[TheNephilim]

Mèh.... ik denk ik maak een repository met static createForUser (cart aanmaken en id opslaan in sessie) en createForGuest (cart aanmaken met user_id) methods die beiden self returnen. Op die manier kun je altijd CartRepository uit service container halen die intern gewoon met een Cart model werkt. Ik dacht met in de service provider die te kunnen initaliseren met één van beide create methods, alleen daar heb ik dan natuurlijk nog geen sessie data