Discussion :

[lutecefalco]

Hello tout le monde

Pour simplifier la chose, j'ai une couche DAL, une couche BLL et un objet métier BO.

Dans ma couche BLL, j'ai une méthode GetById qui va me retourner une instance de BO.

J'ai bien évidemment la même méthode dans ma DAL qui va aller lire en base.

Ma question est:
Qui doit créer l'instance de BO?
* Est-ce que c'est ma DAL?
* Est-ce que ma DAL me retourne un DataReader et c'est ma BLL qui crée l'instance de BO à partir de ce DataReader?
* Autre chose?

Merci

[Guulh]

Mon point de vue : un DataReader est fortement lié au concept de BDD (même s'il existe des providers ADO pour du Excel). Une couche métier n'a pas à savoir que sa DAL pêche des données en base.

[npuzin]

A mon avis ta BLL utilise la DAL mais pas l'inverse. Donc ta DAL ne connait pas ton BO, donc ce n'est pas ta DAL qui instancie le BO.

Tu devrais creer ton BO dans ta BLL a partir d'une datatable ou dataset retourne par ta DAL.

La datatable (ou dataset peu importe) est je trouve un bon moyen de communication entre les differentes couches.

[lutecefalco]

Mon point de vue : un DataReader est fortement lié au concept de BDD (même s'il existe des providers ADO pour du Excel). Une couche métier n'a pas à savoir que sa DAL pêche des données en base.

Yep je suis d'accord là dessus.
Mais pour moi, une DAL ne devrait pas non plus savoir quels objets elle manipule non? Ca devrait juste se limiter à un ensemble de valeurs

[lutecefalco]

A mon avis ta BLL utilise la DAL mais pas l'inverse. Donc ta DAL ne connait pas ton BO, donc ce n'est pas ta DAL qui instancie le BO.

Tu devrais creer ton BO dans ta BLL a partir d'une datatable ou dataset retourne par ta DAL.

La datatable (ou dataset peu importe) est je trouve un bon moyen de communication entre les differentes couches.

Le truc, c'est que c'est lourd un DataSet (ou DataTable)

[skatanick]

Personnellement, je crois que la création des objets est complètement reliée à la DAL. L'objet sert uniquement à retourner l'information de la DB.

A mon avis ta BLL utilise la DAL mais pas l'inverse.
Tu devrais creer ton BO dans ta BLL a partir d'une datatable ou dataset retourne par ta DAL.

La datatable (ou dataset peu importe) est je trouve un bon moyen de communication entre les differentes couches.

Je ne suis pas vraiment d'accord. En utilisant le Dataset, on se retrouve à créer 2 fois des objets "lourd".

[Mehdi_ab]

Bonjour,

Tu peux aussi avoir des BODAL (business object pour la dal) et des BOBLL, cad que tu peux avoir des objets pour un transfert dal vers bll et des objets propres a la BLL, comme ça tu évite un DataTable ou un Dataset.

Comme ça si par exemple j ai un BO Produit, j'aurai donc deux class : ProductDAO et Product (le deuxiéme c'est pour la BLL).

[npuzin]

Le truc, c'est que c'est lourd un DataSet (ou DataTable)

C'est vrai que le dataset est plus gourmand, mais il a des fonctionnalites sympas dont tu as besoin assez souvent.

Si tu veux economiser des ressources au maximum, ta 2eme option me parait bonne:

"Est-ce que ma DAL me retourne un DataReader et c'est ma BLL qui crée l'instance de BO à partir de ce DataReader?"

A condition d'utiliser le IDataReader, qui je pense n'est pas lie a une DB (possibilite lire excel, xml, etc)

[Chubyone]

Mon point de vue : un DataReader est fortement lié au concept de BDD (même s'il existe des providers ADO pour du Excel). Une couche métier n'a pas à savoir que sa DAL pêche des données en base.

+1


La BLL n'a certainement pas à connaitre les Datatruc et machin.. rien, ni meme les Webservices, ni meme le XML, queutchi! Elle fait du METIER, rien d'autre!

C'est pour ca qu'on dit : "Bonjour l'injection de dépendances"! et qu'on travaille avec des interfaces.

[lutecefalco]

+1


La BLL n'a certainement pas à connaitre les Datatruc et machin.. rien, ni meme les Webservices, ni meme le XML, queutchi! Elle fait du METIER, rien d'autre!

C'est pour ca qu'on dit : "Bonjour l'injection de dépendances"! et qu'on travaille avec des interfaces.

Ok, DataReader, c'est pas un bon exemple. Prenons DataTable à la place.
Ton injection de dépendances répond pas pour autant à ma question...

[Maniak]

Ton injection de dépendances répond pas pour autant à ma question...

Pour reprendre le principe d'utilisation des interfaces et d'injection de dépendances, petit exemple d'une possibilité.

Au niveau du domaine, tu as des interfaces :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
  public interface IClient
  {
    int Id { get; }
 
    string Name { get; }
  }
 
  public interface IClientRepository
  {
    IClient FindById(int id);
  }

Au niveau de l'accès aux données, tu as l'implémentation de ces interfaces :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
  public class Client : IClient
  {
    public Client(int id, string name)
    {
      Id = id;
      Name = name;
    }
 
    public int Id { get; private set; }
 
    public string Name { get; private set; }
  }
 
  public class ClientRepository : IClientRepository
  {
    public IClient FindById(int id)
    {
      ...
    }
  }

Au niveau métier, tu ne passes que par des interfaces :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
  public class BusinessThingy
  {
    private readonly IClientRepository _clientRepository;
 
    public BusinessThingy(IClientRepository clientRepository)
    {
      _clientRepository = clientRepository;
    }
 
    public void Bleh(int clientId)
    {
      var client = _clientRepository.FindById(clientId);
 
      ...
    }

L'injection de dépendances est là.

La couche métier ne traite que des objets métier donc de toute façon, c'est ce que tu dois avoir en sortie de ta couche d'accès aux données. Les interfaces, c'est grosso modo un troisième groupe, à la fois pour isoler les traitements métier de l'implémentation de l'accès aux données (fait main ou ORM, ça ne se voit pas) et pour éviter les dépendances cycliques entre les deux. Pas forcément vital selon la taille du projet, mais c'est un exemple :)

Et donc l'accès aux données à proprement parler, ça se fait dans le repository, de la manière que tu veux. ORM, SQL direct, DataReader, DataTable, tout fait par le repository ou passant par plein d'autres classes, ... c'est la cuisine interne. Tout ce qui compte, c'est qu'en sortie tu aies un objet métier. Tu le crées via l'implémentation spécifique à ta couche d'accès aux données et tu retournes son interface 'neutre'.

Après ça, ta couche métier vit sa vie tranquillement.

[lutecefalco]

oki

[npuzin]

Je repensais a l'idee de retourner un IDataReader, mais je pense que tu ne peux pas faire ca, car tu dois maintenir ta connexion DB ouverte ainsi que ta DbCommand aussi longtemps que tu utilises le reader. Ce qui t'obligerait a ouvrir la connexion dans la BLL

Tu peux aussi utiliser l'entity framework ds le .NET 3.5. Y a tu pense ?

[Guulh]

L'inconvénient que je trouve à ce que les couches supérieures manipulent des interfaces IClient plutôt qu'un objet IClient, c'est que le binding peut mal fonctionner.

Par exemple, je fais hériter mes interfaces métier d'une interface mère style IHasId : { int Id { get; } }.

Alors si je binde une collection de IClient à une grille, le binding sur la propriété Id ne fonctionne pas car la méthode GetProperties(typeof(IClient)) ne renvoie que les propriétés directement définies dans IClient, pas celles héritées de sa(ses) interface(s) mère(s).

[Chubyone]

En fait, en bossant en DDD, mes objets métiers sont de purs objets : les Interfaces deviennent obsoletes (et il faut l'avouer, maintenir autant d'Interface que de BOs + autant que de DAOs... F***.)

(Et je bannis d'office l'héritage -sauf cas extremement particulier, et je préfere passer par une classe abstraite)

Les Repositories (qui font office de DAOs, mais plus particulier) sont des Interfaces, c'est surtout eux qu'on injecte. Ils renvoient donc des objets / collections métiers.


Tu peux très bien bosser avec des DataSets... Je connais quelques personnes mordues / fondues / vouant un culte aux DataSets : ils ont leur vision, la défendent, et je la comprend / l'accepte.
Mais alors ne mélangeons pas un mode a base de DataSets et un autre a base d'objet métier et de mapping OR.

Pour rebondir sur Entity Framework : la version 1 n'est vraiment pas mature. Ou alors tu acceptes que tes objets métiers soient fortement corréler avec ton accès données (et dans la même assembly), et que tu ne puisses pas les faire hériter d'un objet personnel.

La V4 (V2) sera plus bien plus intéressante.

[Mehdi_ab]

Salut Chubyone

J'ai commencé a regarder un peu la DDD (domain driven design) mais j'avoue que j'ai pas bien saisi ce qu'il apporte par rapport a ce qui existe maintenant.

Tu peux nous faire stp un petit retour d'expérience, meme si vous avez des exemple du code ça sera vachement sympa.

Par avance Merci