-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IRestCollection : better naming #208
Comments
Le terme |
Pour ma part je préférerais qu'on garde Service pour justement tous les services qui ne gèrent pas des entités, pour faire la distinction au premier coup d'oeil. On pourrait simplement renommer IRestCollection en IEntityCollection du coup = une collection qui gère des entités. C'est lié à l'autre Issue, mais si on vire la classe EntityBase, dont le base faisait référence au fait que c'était une super classe, on pourrait renommer IEntityBase en IEntity tout court, et ainsi donner encore plus de sens à IEntityCollection. |
C'est dommage de pas reprendre la terminologie DDD pour Services
Peux-tu donner des exemples ? je ne vois pas à quoi tu fait référence |
Je n'ai trouvé aucun exemple dans Lucca.Faces ou Lucca.Auth, parce que tout le code métier du Domain est encapsulé dans des collections et les entités liées. Mais j'ai trouvé un exemple dans Poplee.Talent : https://github.com/LuccaSA/Poplee.Talent/blob/rc/back/Poplee.Talent.Domain/Reviews/Services/ReviewsPreparer.cs C'est plus un Helper, mais ce service pourrait dépendre de plusieurs collections pour faire son traitement. De manière générale, je te laisse regarder partout où y'a le terme "service" dans Poplee.Talent, tu verras qu'il y a papa/maman :'( Donc si on ouvre la porte à mettre aussi des "services" pour gérer les entités, pour moi c'est la fin de la "bonne" organisation des projets. |
L'apparition du terme REST dans le domain est en effet assez surprenant. Peut-on trouver un meilleur nom ?
The text was updated successfully, but these errors were encountered: