Comment mémoriser l'utilisateur qui a créé un objet
1 réponse
ShadowFil
Bonjour,
Dans notre logiciel d=E9velopp=E9 en C#, on doit m=E9moriser=20
l'utilisateur qui cr=E9e chaque objet. Logiquement, il=20
suffirait d'associer la classe de l'objet =E0 la classe=20
User. Mais si on fait =E7a, beaucoup de classe vont pointer=20
vers la classe User.
N'y aurait-il pas un Design Pattern ou une fa=E7on de=20
simplifier ce probl=E8me, ou une fa=E7on de faire pour que le=20
diagramme de classe UML ou le sh=E9ma de base de donn=E9es=20
correspondant restent lisible ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ambassadeur Kosh
> Dans notre logiciel développé en C#, on doit mémoriser l'utilisateur qui crée chaque objet. Logiquement, il suffirait d'associer la classe de l'objet à la classe User.
oui
Mais si on fait ça, beaucoup de classe vont pointer vers la classe User.
certes, mais en quoi est-ce un probleme ?
N'y aurait-il pas un Design Pattern ou une façon de simplifier ce problème, ou une façon de faire pour que le diagramme de classe UML ou le shéma de base de données correspondant restent lisible ?
la localité. si vous stockez dans une liste un ensemble d'objets qui ont le meme utilisateur, alors la propriété peut porter sur la liste, plutot que sur chaque utilisateur. c'est une "factorisation". apres, vous l'implantez la ou ça vous semble applicable, et comme ça vous arrange.
mais est-ce bien utile d'en arriver la ? que craignez vous ?
> Dans notre logiciel développé en C#, on doit mémoriser
l'utilisateur qui crée chaque objet. Logiquement, il
suffirait d'associer la classe de l'objet à la classe
User.
oui
Mais si on fait ça, beaucoup de classe vont pointer
vers la classe User.
certes, mais en quoi est-ce un probleme ?
N'y aurait-il pas un Design Pattern ou une façon de
simplifier ce problème, ou une façon de faire pour que le
diagramme de classe UML ou le shéma de base de données
correspondant restent lisible ?
la localité. si vous stockez dans une liste un ensemble d'objets qui ont le
meme utilisateur, alors la propriété peut porter sur la liste, plutot que
sur chaque utilisateur. c'est une "factorisation". apres, vous l'implantez
la ou ça vous semble applicable, et comme ça vous arrange.
mais est-ce bien utile d'en arriver la ?
que craignez vous ?
> Dans notre logiciel développé en C#, on doit mémoriser l'utilisateur qui crée chaque objet. Logiquement, il suffirait d'associer la classe de l'objet à la classe User.
oui
Mais si on fait ça, beaucoup de classe vont pointer vers la classe User.
certes, mais en quoi est-ce un probleme ?
N'y aurait-il pas un Design Pattern ou une façon de simplifier ce problème, ou une façon de faire pour que le diagramme de classe UML ou le shéma de base de données correspondant restent lisible ?
la localité. si vous stockez dans une liste un ensemble d'objets qui ont le meme utilisateur, alors la propriété peut porter sur la liste, plutot que sur chaque utilisateur. c'est une "factorisation". apres, vous l'implantez la ou ça vous semble applicable, et comme ça vous arrange.
mais est-ce bien utile d'en arriver la ? que craignez vous ?
