Déjà d'un point de vue organisation, createFlight doit être une méthode de Flight ou FlightManager, peut importe qui l'appelle, elle concerne le vol, et sera bien mieux ici... la vérification pourrait bien être située dans createFlight, ce serait logique. Mais c'est le cas usuel de la patate chaude en informatique. Dois-je mettre la sécurité en amont en en aval d'une fonction donnée ? Tu peux tout à fait considérer qu'une méthode dois vérifier elle-même sa légalité en fonction d'élements proches de son environnement. Ici ça dépend plus de la situation de la Seelie, que de paramètres internes à Flight, donc il vaut mieux le test du côté Seelie, pour la cohérence.
Ensuite, pour la vérification, c'est un problème qui m'embête aussi, si c'est par post, il faut bien entendu vérifier, et si tu as les infos nécessaire en session ce ne sera pas trop cher, (contrairement à une action dont il faut vérifier la validité en rapatriant des infos en bdd...) l'autre solution étant d'envoyer une information de validité codée, ce qui peut devenir une usine à gaz...
Enfin, il faut penser aux problèmes de l'usage asynchrone. Imaginons un cas bête : la seelies demande à effectuer une action disponible pour qui appartient à un VOL. Entretemps, elle en a été chassée par qui de droit. Paf, sans vérification en BDD, elle va pouvoir faire une action illégale à son corps défendant, puisque ses infos de Session confirmeront que oui, elle est dans un vol (à moins qu'un utilisateur puisse changer la session d'un autre par ses actions.. est-ce seulement possible ?) donc il faut réserver cette approche à tous les éléments dont il est quasi certain qu'ils ne peuvent changer le temps d'une session, sans action volontaire du joueur.
Ensuite, pour la vérification, c'est un problème qui m'embête aussi, si c'est par post, il faut bien entendu vérifier, et si tu as les infos nécessaire en session ce ne sera pas trop cher, (contrairement à une action dont il faut vérifier la validité en rapatriant des infos en bdd...) l'autre solution étant d'envoyer une information de validité codée, ce qui peut devenir une usine à gaz...
Enfin, il faut penser aux problèmes de l'usage asynchrone. Imaginons un cas bête : la seelies demande à effectuer une action disponible pour qui appartient à un VOL. Entretemps, elle en a été chassée par qui de droit. Paf, sans vérification en BDD, elle va pouvoir faire une action illégale à son corps défendant, puisque ses infos de Session confirmeront que oui, elle est dans un vol (à moins qu'un utilisateur puisse changer la session d'un autre par ses actions.. est-ce seulement possible ?) donc il faut réserver cette approche à tous les éléments dont il est quasi certain qu'ils ne peuvent changer le temps d'une session, sans action volontaire du joueur.