Plusieurs objet metier en un

Version imprimable

21/07/2009, 13h17
topolino

Plusieurs objet metier en un

Bonjour,

Je dois afficher des donnes ds un gridview, ces donnees proviennent de plusieurs objets metiers. j'ai donc un objet metier qui contient plusieurs objets metiers, ce qui m'embetes est de tous charger hors que j'ai juste besoin de qqs proprietes de chaque objets metiers.

que me conseilleriez vous ?

merci
21/07/2009, 13h19
Arthis

au choix :

1) de faire du lazy loading pour chacun de tes objets metiers et leur propriétés
2) si ta requete est trés gourmande en ressources de faire quelque chose de particulier à cette requete afin de retrouver tes données
21/07/2009, 13h28
topolino

As tu une doc sur le lazy loading ?
21/07/2009, 13h55
Arthis

non mais ces liens devraient eclairer ta lanterne :

http://en.wikipedia.org/wiki/Lazy_loading
http://wiki.asp.net/page.aspx/408/lazy-loading/

Dans l'exemple suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public class Order{    
private int _OrderId = 0;    
private int OrderId    {        
set { _OrderId = value; }        
get { return _OrderId; }    
}    
private Customer _Customer = null;    
public Customer Customer    {        
get        {                
if (_Customer == null)                
_Customer = Customer.GetCustomerByOrderId(_OrderId); // Lazy loading the Customer            
return _Customer;        }        
set { _Customer = value; }    }
}

Cela veut dire que Customer.GetCustomerByOrderId(_OrderId); doit faire appel a la couche metier ?

21/07/2009, 15h03
Arthis

j ai toutjours ete mauvais avec ce vocabulaire de couche metier, business et tout le tralala.. Moi ce que j'en ferais mais je n'ai pas non plus enormement d'experience avec ce genre de trucs,c 'est un service qui me creerait un objet et qui irait demander á la couche de données toutes ses informations. C'Est ca la couche métier?
21/07/2009, 15h56
topolino

La couche accees aux donnees (select * from user) remplis les objets metiers (user)
La couche metier va appeler la/les methodes de la couche accees aux donnees afin de recuperer l'objet user afin d'y operer d eventuelles traitements.
L UI va appeler la methode metier sans se soucier de qulle bdd il s agit.....

Par consequent l'objet metier User (contient toutes les prop) qui ont ete renseignes dans la couche acces aux donnees.

C'est pour cela que ca me parait etrange que l'objet metier doit appeler une methode de la couche metier
21/07/2009, 16h43
Arthis

je ne vois pas ce qu il y a d'etrange la dedans. Moi c'est mes objets services qui creent des objets metiers en allant taper dans des repository ( couche de données).

Ensuite, mon UI traites ces objets metiers pour les afficher comme bon lui semble. Mes objets metiers ne contiennent presque aucune fonction. tout est empaqueter dans les objets services.

Maintenant, il y aura des langues plus expertes que moi pour te détailler le top du top , j'en suis sur.. Bon courage à toi en tout cas, a+
21/07/2009, 19h34
Kaidan
J'aurais fait un objet minimal avec les propriétés que je suis sûr d'avoir besoin dans tous les cas (dont l'affichage de la GridView) et qui charge les données minimales puis j'aurais étendu cette objet pour avoir un (ou plusieurs) objet étendus qui chargent plus (voir toutes) les données. Bien entendu, il faut ensuite passer par une Factory pour construire correctement (et de façon optimale) les objets et non pas passer par un constructeur.
Code:

1 2 3 4 5 6 7 8 9 public class OrderRef { public OrderId { get; set; } } public class Order : OrderRef { public Customer Customer { get; set; } }
On peut également ajouter une méthode pour obtenir un Order depuis un OrderRef.
22/07/2009, 11h46
topolino

Ce qui m'embete c'est que dans ma DAL je reference le projet ou se trouve tous les objects metiers, par consequent je ne peuxpas dans mon projet objet metiers referencer ma DAL !!!!!
22/07/2009, 13h13
Arthis

Dans ta couche metier, tu ne fais pas appel a ta dal, mais à l'interface qui permet d'accèder a ta dal.
22/07/2009, 14h23
topolino

Entre mes differentes couches je ne passe pas par des Interface, mais je vais sans doute faire alors.
22/07/2009, 14h37
topolino

L'interface elle est egalement dans le projet DAL, donc ca ne changera pas mon probleme
22/07/2009, 16h33
Arthis

Fais tes interrfaces dans ton projet metier alors..

[edit] on a le meme nombre de messages maintenant... hé hé! [/edit]
22/07/2009, 16h53
topolino

Ah oui cool, et pourtant j'avais 3 mois d'avance sur toi ;o)

Sinon je ne peux pas mettre mes interfaces DAL dans le projet Metier ?!?
Comment decoupes tu tes projets dans ta solution ?
22/07/2009, 17h19
Arthis

je ne suis pas un bon moi j'ai qu une seule librairie avec tout dedans dans des repertoires séparés... :(

J'ai deja réussi à avoir un bibliotheque de classe dans mon projet web et cela a été une petite révolution dans ma boite...
23/07/2009, 09h50
topolino

Je ne sais pas comment faire alors !!!!! Car pour l'instant ma dal et bll reference mes objects metier, donc de mes objets metier je ne peux pas referencer ma dal et bll !!!!!
23/07/2009, 11h21
Arthis

Lutecefalco aurait surement une réponse pour toi je pense. Je me rappelle qu il parlait du découpage de ses applis web en plusieurs projets..
23/07/2009, 14h11
topolino

Esperons qu il passe par ici.

Merci à toi
24/07/2009, 05h24
Kaidan

Hum ... si on est logique :

Le client (interface graphique etc.) utilise les objets métiers qui utilise la couche d'accès aux données ... donc le référencement devrait être client référence objets métiers référence couche d'accès aux données (et pas le contraire). C'est le concept de base d'une architecture n-tier : le client n'a pas à avoir accès direct à la couche d'accès aux données et doit pouvoir totalement ignorer comment sont persistés les objets à l'intérieur de celle-ci.

Cas concret : sur une application, je clique sur "Ajouter nouveau client" ... l'application créé un nouveau client (de la couche objet métier), renseigne les différentes informations puis effectue une sauvegarde du client (en appelant une méthode de la couche métier qui appele de façon transparente pour le client la couche d'accès aux données).

Les interfaces entre objets métiers et couche d'accès aux données n'ont d'intérêt que si on peut avoir plusieurs couches d'accès aux données (par exemple, base de donnée, fichier xml etc.). 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.
24/07/2009, 09h10
topolino

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.
24/07/2009, 10h12
Kaidan

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.
24/07/2009, 16h35
topolino

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 ?
26/07/2009, 14h19
Chubyone

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... :)
27/07/2009, 13h33
topolino

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 ?
27/07/2009, 14h17
Kaidan

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:
27/07/2009, 14h30
topolino

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 !!!
27/07/2009, 15h49
Kaidan

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.
28/07/2009, 09h04
topolino

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... } }

28/07/2009, 15h50
topolino

Merci c'est beaucoup plus claire.

Genial