Plusieurs objet metier en un

Kaidan je pense que tu as confondu Couche metier (Business logic access) et les Objets metiers (Business object).

Le client a access a la BLL (couche metier) qui elle a acces a la DAL (Couche access au donnees). Ce qui ton transite entre les differents couches ce sont les Objets metier (Business object).

les Objets metier sont renseignes par la DAL, peut etre transforme par la BLL et afficher par l'UI.

Ce dont il est question ici c'est d'appeler la Couche metier a partir des objets metiers pour faire du Lazy loading, et c'est en cela mon probleme.

Hum ... ça te fait 4 couches. Je n'en vois pas bien l'utilité.

Quand je développe un objet métier, je n'y code pas uniquement des propriétés pour que, d'un côté le client puisse afficher les données et de l'autre côté la couche d'accès aux données enregistrer ces mêmes données. Je ne me sers pas uniquement de mes objets métiers pour avoir un support de communication entre mes différentes couches parce que je sais pertinement que j'ai besoin de logique dans ces objets et que je veux que cette logique soit validée, aussi bien du côté client, que du côté accès aux données.

C'est pourquoi ma logique métier se trouve encapsulée dans les objets métiers. Je veux être sûr que le client ne puisse pas mettre une référence null dans la variable Display avant que l'objet arrive à la couche d'accès aux données (ou à un autre couche) ou que cette même variable Display ne puisse recevoir une référence null depuis la base de donnée (dans lesquels les données seraient dans ce cas corrompues).

Lorsque les objets métiers contiennent la logique métier et la logique d'utilisation de la couche d'accès aux données (j'ai bien dit logique d'utilisation, pas logique de comment la couche d'accès stocke physiquement les données), alors tu ne te poses plus de question sur comment accèder à ta couche d'accès aux données depuis tes objets métiers en Lazy Loading.

J'ai tres longuement reflechis a ton dernier post.

en faite tes objet metier == ma couche metier et
mes objet metier == les DTO

Ce qui est pas forcement logique en effet.

Si j'ai bien tout compris tes objetc metier sont construit a partir de tes DTO ?

Citation:

---

Envoyé par topolino

Si j'ai bien tout compris tes objetc metier sont construit a partir de tes DTO ?

---

Il construit ses objets métiers suivant + ou - le principe du DDD. On ne parle plus alors de DTOs : les BO sont la définition et les traitements métiers.

Dans ce cas de figure tu as un "Domain" qui contient des objets métiers, qui -suivant la bonne logique objet- contiennent eux mêmes la logique métier.
Ce Domain contient également des Interfaces définissant des Repositories : c'est eux qui vont renvoyer les objets métiers du DataStorage (tu peux les voir comme des DAOs, mais pas exactement. Tes Repositories n'exposent déjà que des possibilités "métiers").
Tes objets métiers connaissent eux même ces interfaces de Repositories : ils accèdent donc facilement au DataStorage pour que tu puisses implémenter ton LazyLoading.

Et comment accéder à des classes concrètes qui sont dans une autre assembly? C'est ici que tu dis bonjour aux IOCs et à la dependency injection. Ainsi, l'assembly de tes classes concrètes référence ton assembly Domain : pas de référence circulaire.


Mais pour moi il y a toujours un hic : tes objets métiers peuvent avoir besoin de charger un autre objet métier : ok. Mais implémenter dans chaque propriété de chaque objet un LazyLoading, c'est un peu lourd et c'est tout simplement pas "métier" pur.
Et quand tu utilises nHibernate, tu sais qu'il est capable de gérer le LazyLoading lui même de tes objets (et surtout le Eager loading, qui au final est bien plus intéressant... Attention aux effets de bords de ton LazyLoading et les milliers de requêtes SQL balancer si tu fais une "toute petite" boucle)

Il y a des solutions, mais faut quand même voir à pas se toucher la nouille trop loin :aie:.

Citation:

---

Si c'est un développement où on est sûr de toujours utiliser SQL Server par exemple, c'est du temps de développement perdu.

---

Par définition on est jamais sur de rien. On est encore moins sur que la structure de données ne va pas changer (c'est d'ailleurs ce qui change le plus souvent) : de ce principe adapter rapidement l'ORM ou tout simplement switcher d'ORM grâce aux interfaces n'est pas du tout un luxe.

Des Interfaces pour l'accès aux données, c'est un must have.
Sinon autant planter des SQLDatasources et ne créer que des ProcStock, on est au même niveau... :)

Merci pour ton explication et d'y avoir pris la peine.
J'ai du mal a bien comprendre le pattern IOC.

En faite voila comment je procede en gros.

Dans ma solution :

Projet DTO
-Client

Projet DAL
-GetClient(Client client) --> oblige de referencer le projet DTO si je veux le mettre en parametre

Projet BLL
-GetClient(Client client) --> oblige de referencer le projet DTO si je veux le mettre en parametrre et DAL
Et j'opere des regles metier a c e niveau la.

Comment decoupler tous ca avec ton pattern ?

Bonne explication chubyone, j'avais pas eu le temps d'y répondre 8-)

Je ferais, pour ne pas trop avoir à modifier le code :

Interface : IClient
DTO : Client [référence Interface]
DAL : GetClient(IClient) [référence Interface]
BLL : GetClient(IClient) [référence Interface]

Après, il faut injecter DTO dans DAL et BLL au runtime pour pouvoir construire des Client (implémente IClient).

Mais bon, tu vois bien qu'il y a un soucis entre ta DAL et BLL ... même méthodes, c'est louche :roll:

Mon exemple effectivement n'est du meilleur choix car ma BLL ne sert que de passe/plat ds ce cas precis, mais je voulais un exemple simple.

Mais que mets tu ds l'interface IClient ?
En faisant comme ca je ne pourrais toujours pas faire du lazy loading !!!

Je suis toujours pas convaincu que le lazy loading soit la meilleure solution dans ton cas.

Comme tu le dis : "j'affiche mes objets dans une DataGridView mais je n'ai pas besoin de toutes les propriétés pour les afficher".

Je suis donc toujours d'avis de créer deux objets, un avec les propriétés juste nécessaires et puis l'autre avec toutes les propriétés (le second pouvant dériver du premier pour factoriser le code), et un moyen depuis l'objet minimal de récupérer un objet complet.

Dans le projet Interface, je mettrais juste l'interface des objets de la DTO (propriétés, méthodes publiques) pour que toutes les couches puissent y avoir accès.

En faite j'ai une DTO Client dans laquelle une propriete de type List pointe sur une autre DTO.

Je ne veux pas charger cette propriete car je m'en sert pas dans chaque cas, d ou le lazy loading.

Comment fais tu pour ne charger que ce que tu veux alors, par des constructeurs differents ?

Si une propriété n'est pas chargée ... elle n'est pas dans mon objet. Le seul cas où j'utilise du Lazy Loading, c'est pour charger une propriété qui a un impact fort sur les performances lors de la création de l'objet ou d'encombrement mémoire (style un fichier par exemple) alors que je sais que j'ai 1/10 chances de l'utiliser au final.

Comme je t'ai expliqué, j'utilise deux objets :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public class ClientRef { public int Id { get; set ; } public ClientRef(int id) { /* ... */ } }   public class Client : ClientRef { public List<Commande> Commandes { get; set; } public Client(int id) : base(id) { /* ... */ } }

---

Ensuite dans ta DAL, tu peux faire un :

Code:

---

1 2 3 4 5 6 7 8

public class ClientDAL {   public void GetClient<T>(ref T client, int id) where T : ClientRef { // code pour construire les objets... }   }

---

Merci c'est beaucoup plus claire.

Genial