Discussion :

[lucastof]

bonjour!
ma question est un peux bizarre mais je vais vous expliquez
j'ai un serveur contenant plusieurs base de données qui contiennent plusieurs tables
dans une DLL communes j'ai mis mes entités qui représentent les tables donc j'ai autant d'entités que de table
sachant que j'ai un nombre assez important de table donc je me retrouve avec un code source alourdi de classes
au niveau de ma couche BL je fais des processus qui utilise ces entités donc si ma procédure stockés touche 4 ou 5 table je dois manipulé les 5 entités constituer un dictionnaire contenant des propriétés des 5 entités et les envoyer a la procédure stockée.
ma question est ce la bonne façon de faire ou alors il serai mieux de créer une entité mappé au business (Contenant les attributs selon besoin seulement) au lieu de la table.
merci

[dkmix]

Bonjour,

ma question est ce la bonne façon de faire ou alors il serai mieux de créer une entité mappé au business (Contenant les attributs selon besoin seulement) au lieu de la table.

Je ne sais pas si c'est "la" bonne façon de faire, mais il est possible d'avoir des objets métiers ou de transfert (DTO) différents des entités "Table".
Si çà permet de factoriser et de simplifier la couche métier c'est tout à fait envisageable. Cela permet également de découpler la couche d'accès aux données (si il y en a une) et la couche métier.
En contrepartie, Il faut ajouter un mappage supplémentaire ou une encapsulation des objets tables dans les objets métiers.

[champsy_dev]

Attention une table = une entité c'est le concept de base Table-Per-Type mais ce n'est pas toujours le cas tu peut aussi faire du mapping Table-per-Hierarchy Inheritance, en gros une table par niveau de la hiérarchie d'héritage, c'est peut être la réponse à ta question ....