Discussion :

[newkiss]

Bonjour,

J'ai une problématique sur la conception de classe métier (C#/ Java ...) qui serait une image d'une table de BDD.
Je souhaite que mon application soit toujours une réalité de ma BDD (Mode connecté)

Exemple :

Table "Societe" , "Salarie"
Une société --> Plusieurs Salariés
Un Salarié --> Une Société

Laquelle des 2 solutions suivante serait la plus judicieuse : (ou une autre)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Societe {
     int idSociete;
     string nom;
 }
class Salarie{
     int idSalarie;
     string nom;
     string prenom;
     int idSociete;
 }

OU

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
class Societe {
     int idSociete;
     string nom;
     List<Salarie> listSalarie;
 }
class Salarie{
     int idSalarie;
     string nom;
     string prenom;
     Societe maSociete;
 }

Merci d'avance pour vos réponse

[CinePhil]

Je pense qu'en programmation objet, c'est plutôt la seconde forme qui est la bonne.

Maintenant, ce qui peut être gênant si c'est mal fait, ce serait que l'instanciation de la classe Société pour une société lance automatiquement la récupération de la liste des salariés si l'application n'en a pas besoin au moment de cette instanciation !

Si j'ai besoin de l'adresse du siège de la filiale Tartempion, je ne vais pas rapatrier la liste de ses 1300 salariés !

[newkiss]

C'est effectivement ce que je pensait. Je ne développe pas en objet habituellement. C'est pourquoi ce concept de charger des références comme cela me semble un peu lourd.

Je suis ouvert à d'autres informations pour comprendre un peux mieux ce qui est bon ou non (Avantage / Inconveniant) des deux techniques.

Mon but étant d’essayer de coder le plus proprement possible en objet (En C# dans mon cas)

[CinePhil]

Je ne suis pas spécialiste en développement objet, surtout en Java que je connais peu et en C# que je ne connais pas du tout !

Mais il me semble que le constructeur de la classe Societe ne devrait pas lancer un getListeSalaries qui ne devrait être activié qu'à la demande. La propriété listSalaries devrait donc être, selon moi, initialisée à vide.

On peu d'ailleurs imaginer que la classe Societe pourrait être utilisée pour créer une nouvelle société puis pour y ajouter des salariés, ce qui justifie la listSalaries à vide.

Maintenant, place aux experts !

[bruno_pages]

Bonjour,

je suis d'accord avec l'ensemble des réponses de CinePhil.

Je souhaite que mon application soit toujours une réalité de ma BDD

Je suppose que cela veut dire que la BDD est modifiée en dehors de l'application courante, sinon le problème ne se poserai pas.

Ce que vous souhaitez risque fort de n'être qu'un vœux pieu, car vous aurez toujours un décalage avec le contenu de la BDD à chaque fois qu'elle bouge.

Attention de bien avoir une image cohérente du contenu de la BDD, lorsque plusieurs informations formant un tout cohérent sont modifiées, suivant le moment ou votre lecture sera faite vous risquez un mélange entre des anciennes valeurs pour des informations et des nouvelles valeurs pour d'autres. A confirmer par CinePhil mais le moyen de se protéger est déjà de faire les écritures en BDD via des transactions/verrous.

[newkiss]

J'ai en fait l'impression en chargeant des éléments provenant d'une requête en BDD dans un objet, que si je réutilise ce même objet pour charger des informations à l'écran, celui-ci (objet) ne sera pas forcément synchroniser avec la BDD.
De plus cela me donne aussi l'impression de charger beaucoup d'informations en mémoire alors que celle-ci ce seront par forcément utile pour mes traitements

Je ne programme pas en objet habituellement et suis un peu dérouté par ce fonctionnement. En général (en non objet), je requête simplement ma base puis en affiche directement (ou après traitement) le résultat.

Après, si les experts objet me disent que cette ainsi, c'est que cela ne doit pas pauser plus de problème que cela

[bruno_pages]

Bonjour,

le fait que vous mémorisiez ou non les informations n'a rien a voir avec le fait que vous programmiez 'objet' ou non, car vous pouvez tout aussi bien mémoriser vos informations via des structures C.

ce que vous devez savoir c'est si vous devez ou non mémoriser les choses à au moins moyen terme.

mais pour vos affichages/traitements il faudra bien que vous ayez au moins des mémorisation temporaires, et là vous pouvez très bien programmer 'objet'