Architecture accès aux données.

Bonjour,

J'ai mes entités (objets métiers) qui sont mappées sur des tables de ma base de donnée.

J'ai une assembly qui contient mes objets métiers, et j'ai une DAL qui me permet de charger des collections de ces objets métiers.

En terme de dépendance, l'assembly de ma DAL utilise l'assembly de mes objets métiers.

J'ai 2 entitées : Client et Commandes. J'aurais besoin sur ma classe Client d'implémenter une propriété List<Commandes>.

Mon soucis, c'est que du coup, j'aurais besoin dans ma classe Client de connaitre ma DAL pour charger mes Commandes. Et je créé donc une dépendance depuis mon assembly de mes objet métiers vers ma DAL.

Cela me parait pas logique de créer une dépendance dans ce sens.
Qu'en pensez vous ?

Sybaris

Citation:

---

J'ai une assembly qui contient mes objets métiers, et j'ai une DAL qui me permet de charger des collections de ces objets métiers.

---

Dans ce cas la, ce ne sont pas des objets metiers, tes objets, ce sont des DTO -> data transfer objects...

http://en.wikipedia.org/wiki/Data_Transfer_Object

Tes objets métier, normalement, leur but, c'est de te donner une valeur ajoutée (->métier) par rapport a ton système de persistance

Chez moi, ca se traduit par DTO -> DataAccess -> Metier, avec plutôt un pattern style Repository.

Si ton système est mappé directement sur la base de données, utilise un pattern ActiveRecord (tes objets ont la responsabilité de se sauver tous seuls), mais dans ce cas, de la même manière, tu auras DataAccess (wrappers sur la base de données & co.) -> BusinessObjects (objets avec les champs et les fonctions Save & co)...

Citation:

---

Mon soucis, c'est que du coup, j'aurais besoin dans ma classe Client de connaitre ma DAL pour charger mes Commandes. Et je créé donc une dépendance depuis mon assembly de mes objet métiers vers ma DAL.

---

Dans ce cas la, après avoir remonte business au-dessus de DAL, tu utilise une Factory pour charger tes clients...

Genre, dans ta classe Client, ta propriete Commandes, qui renvoie une List<Commande>, tu la code comme ca :

Code:

---

1 2 3 4 5 6 7 8 9

public List<Commande> Commandes{ get{ if (_commandes == null){ _commandes = CommandeFactory.GetCommandesByClientId(_id); } return _commandes; } }

---

(et en plus, ca te gère du lazy loading, elle est pas belle, la vie ;) ?)

Après, cela n'engage que moi, c'est le genre de sujet ou on peut discuter pendant pas mal de jours :aie:, mais depuis, ca a plutot bien marché :mrgreen:

Bonjour,

Tout d'abord merci pour la réponse.
J'aurais cependant quelques questions supplémentaires :
- La classe CommandeFactory sera codée dans quelle couche ? DTO, DataAccess ou Metier ?
- Je pense que je n'ai pas bien compris la différence entre mes classes DTO et mes classes métiers. Est-il possible d'avoir un exemple svp ?

Merci d'avance

Sybaris

Pour les Factory, elles vont généralement dans la couche métier.

pour une différence entre DTO et objets métier, tu peux lire ici:
http://msdn.microsoft.com/en-us/library/ms978717.aspx

Si tu ne lis pas trop l'anglais, en résumé, un DTO est un objet "bête", avec juste les champs nécessaires pour contenir les données, alors qu'un objet métier va avoir des opérations spécifiques.

Par exemple, ton objet commande va probablement avoir une liste d'article, le DTO de commande va avoir date, clientId, adresse, alors que Commande dans la partie métier aura en plus une liste d'articles, une méthode TotalPrice, une méthode AddArticle, et une Removearticle ;)

Bonjour,

Tout d'abord merci pour le lien.
Dans mon cas, je ne suis pas en architecture distribuée, mais je pense que cela ne change rien à l'architecture...

A la lecture de l'article, j'en déduis que dans notre exemple, la classe Client est une classe métier (domain dans l'article), et non une classe DTO, n'est ce pas ?

Si je m'en tiens à l'article, les données sont présentes 2 fois en mémoire : 1 fois dans les objets DTO, et une 2ème fois dans les objets métiers. Je ne trouves pas cela optimisé...
Cela réclame en plus de faire du transfert de données entre les objets DTO et métier...

Sybaris