WIP: feature/Définition-des-entités-métier-et-interfaces #14
Jonathan
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "feature/Définition-des-entités-métier-et-interfaces"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
J'ai bossé dans la feature/1 donc j'ai du tout nettoyer pour repartir de feature/def... C'est parti en couilles avec git, j'ai souffert, je retiendrai la leçon
@ -0,0 +2,4 @@using System.Collections.Generic;using System.Linq;using System.Text;using System.Threading.Tasks;Peux-tu vérifier si ces imports sont vraiment nécessaires ? En général, on évite les imports inutiles pour garder le code propre
Corrigé, je ne nettoie pas assez mes pr avant de les nettoyer, c'est noté
@ -0,0 +8,4 @@{public class Spell{public Guid Id { get; set; }Penses-tu qu'il soit souhaitable qu'un code externe puisse modifier l'Id d'un Spell après sa création l'entité ne devrais pas etre private?
Ce que je retiens de ce commentaire, faire attention à ce qui doit etre accessible en dehors de la classe ou non, en l'occurence, un id devrait etre accessible uniquement en get étant donné qu'il est unique et propre à l'entité, c'est noté
@ -0,0 +12,4 @@public required string Name { get; set; }public required string Type { get; set; }public required string Description { get; set; }public required string Creator { get; set; }Tu veux garder l'entieretée de l'objet User en en memoire pendant ton utilisation de cette entité? Une simple reference ne serait pas mieux?
Donc ici je n'avais pas prévu de one to many, un mage avec plusieurs sorts, simplement des sorts avec un nom de créateur, suite à ta remarque je viens d'apprendre donc qu'il vaut mieux faire une référence à un objet plutôt que de mettre ( public Creator? creator {Get; set;} ) je vais rajouter ceci à la pr.
@ -0,0 +13,4 @@Task<ICollection<Spell>> GetAll();Task<Spell> GetSpellById(Guid id);Task<ICollection<Spell>> GetFilteredSpells(SpellFilter spellfilter);Task<Spell> UpdateSpell(Spell spell);Pourquoi passer un spell entier quand on gagner de la memoire en ne passant que l'id du spell, et des parametres optionnel pour ce qui doit etre modifier?
Afin de fix ceci, je vais créer une classe de style DTO (on peut avoir des dto coté domaine ?) qui elle va gérer les update avec des nullable
@ -0,0 +14,4 @@Task<Spell> GetSpellById(Guid id);Task<ICollection<Spell>> GetFilteredSpells(SpellFilter spellfilter);Task<Spell> UpdateSpell(Spell spell);Task<string> DeleteSpell(Spell spell);Pourquoi le retour est il un string? Pourquoi pas un boolean? Y'a til plus d'information necessaire au retour que effacer ou non effacer?
Qu'en est il de la gestion d'erreur? Pourquoi passer un spell entier quand on gagner de la memoire en ne passant que l'id du spell?
Retour modifié vers un booléen, Concernant la gestion d'erreur elle se fera coté application et API sauf contre indication ?
feature/Définition-des-entités-métier-et-interfacesto WIP: feature/Définition-des-entités-métier-et-interfacesPull request closed