rducom
commented
6 years ago Étant donné qu'on retourne uniquement 1 niveau d'entité en Get je vote pour rester homogène, et ne permettre de choisir que l'approche UserFriendsCollection : PUT /api/friends/2 comme approche par default. A charge au dev de faire un crud custom sur plusieurs niveaux dans leur code si le besoin existe.
L'enjeu qui en découle, serait de permettre de créer un UserFriendsController / Collection / Repo avec un nombre ultra minimal de lignes de code (juste un register ioc du TEntity par ex)
J'aimerais ici qu'on s'attaque à une problématique récurrente, celle des sous API, ou sous Collection.
PUT /api/users/123/friends/2ici on veut mettre à jour le 2ème Friend du User 123Est-ce que le code qui gère cet appel est dans la UsersCollection ? Ou dans une UserFriendsCollection ? Si oui, quelle relation entre ces 2 collections ?
On voit un pattern se dessiner, c'est qu'à chaque fois qu'on est dans ce genre de cas, on est sur 1 seul objet principal (ici le User 123), et sur un seul ou une collection de sous objets (les Friends).
On pourrait donc créer un concept de SubCollection (notamment pour isoler le code dédié aux Friends de celui dédié aux users directement, et qui se trouve dans la UsersCollection), et indiquer qu'elle dépend d'une Collection ou d'un TEntity "parent".
Ainsi, le
UpdateByIdAsync(TKey id)deviendrait unUpdateByIdAsync(TParent parent, TKey id), càd qu'on fournirait à la SubCollection l'entité parent correspondant à l'appel, et les données entrantes notamment l'ID de la sous entité concernée.On pourrait mettre ce code sur la classe TParent directement, en mode DDD puriste, mais ce n'est pas pratique vis-à-vis de l'injection de dépendance, car du coup on va devoir mettre des dépendances sur l'entité parent, ce qu'on veut tous éviter j'ai l'impression. Et ce serait également contraire à SRP, qui dit qu'une entité ne doit pas "trop" en faire.
D'une sous entité à une commande il n'y a qu'un pas.
POST /api/users/123/move, un move étant un déménagement, avec une adresse, une date prévisionnelle, etc..Ici on est dans le même cas de figure, et si on considère que les commandes sont des entités à part entière, alors le cas revient au cas précédent = pas de différence entre un Friend et un Move.