Discussion :

[CécileH]

Bonjour,

J'essaie d'organiser mes projets en 3 tiers (présentation, métier et données). Dans mes projets précédents, j'ouvrais les bases de données juste avant d'effectuer mes requêtes, donc dans la couche données.
Pour un nouveau projet, j'ai besoin d'ouvrir les connexions au début de l'application et de les refermer à la fin car j'ai beaucoup de requêtes à exécuter et ce serait trop long d'ouvrir la connexion à chaque fois.

Pour le moment, j'ouvre mes connexions dans la couche présentation et je les passe en paramètres vers la couche métier puis vers la couche data mais je ne pense pas que cela respecte l'architecture 3 tiers. Il me semble que la couche présentation ne doit pas référencer la couche données.

Merci d'avance de votre aide.

[Sankasssss]

Bonjour,

les connexions peuvent être ouvertes et fermées à chaque fois sans soucis si vous interrogez une base de donnée digne de ce nom car elles ont un pool de connexions qui gère cela...

[J@ckHerror]

Bonjour,

Pour le moment, j'ouvre mes connexions dans la couche présentation et je les passe en paramètres vers la couche métier puis vers la couche data mais je ne pense pas que cela respecte l'architecture 3 tiers. Il me semble que la couche présentation ne doit pas référencer la couche données.

Comme le dit sankasssss tu peux très bien ouvrir une connexion,faire ta requête, fermer la connexion et recommencer à souhait, le serveur est normalement fait pour ça. Tu peux même par exemple encapsuler la partie connexion et requête vers ton serveur dans une dll maison, ainsi tu n'auras plus a te préoccuper (et à copier coller surtout...) de cette partie, tu passe une requête à la dll, elle te retourne le résultat...

Sinon oui l'idée serait que ta couche de présentation n'ai qu'une vue très abstraite de la couche de donnée. Tu trouveras sur le net pas mal de documentation qui illustre ces trois couche les une au dessus des autres : présentation qui communique avec métier qui communique avec data. Mais encore la je trouve que c'est perfectible, et on peut rajouter de l'abstraction en utilisant le principe des repository, c'est à dire que ta couche de présentation ne connait que les interfaces décrivant tes repository qui eux sont chargés de fournir tes object métiers. On est pas vraiment sur du une couche au dessus de l'une autre, puisque la couche métiers n'a alors aucune connaissance de la couche data. seule la couche data à connaissance des la couche métier.

regarde un peu sur le net pour te faire une idée mais je te mets un tout petit exemple pour illustrer :

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
//metier
public class MaClasse
{
    public string P1{get;set;}
    public int P2{get;set;}
    public int P3{get;set;}
    ....
 
 
}
//db
public interface IMonRepository
{
    IEnumarable<MaClasse> GetMaClasses();
    bool insert(MaClasse o);
    ....
}
public class MonRepository_SQL : IMonRepository
{
    IEnumerable<MaClasse> GetMaClasses()
    {
        //on requete et on instancie les objects...
    }
    bool insert(MaClasse o)
    {
        ...
    }
    ...
}
//UI
public static Main
{
    IMonRepository _repo = new MonRepository_SQL(); 
    ....
    IEnumerable<MaClasse> lstObjectMetier = _repo.GetMaClasses();
    ...
 
}

Du coup comme tu peux le voir le metier ne fait que du métier, et en modifiant une ligne tu peux changer de repository et donc de source de donnée, j'ai mis pour l'exemple un repo SQL mais tu pourrais par exemple te faire un repo Txt pour aller chercher tes données dans un fichier txt juste pour faire des tests par exemple pour tester ton métier ...

Renseigne toi un peu et hésite pas si tu trouve cela adapté à tes projets.

Bon code,
J@ck.

[Invité]

Bonjour,

Une organisation en trois tiers a pour objet de ne pas à avoir à réécrire la totalité de son code si d'aventure nous voulions réutiliser tout ou partie du code dans un autre environnement client!

Le client (IHM).

Je pourrais confier les IHM à un infographiste; la partie base de données à un DBA; me consacrer à la partie métier et syncristalliser le tout!

Le client dialogue avec le métier,il lui envoi des demandes et ce contente d'afficher la réponse.

Le métier à pour charge de qualifier le demande de IHM mais il ce fiche complètement de savoir si IHM est un userform, une page web ou une page console. C'est le métier qui dialogue avec la base de données!

Et enfin la base de données.

3 tiers (client,métier,base de données). En d'autre terme chaque ihm dispose d'une classe métier et un classe Sql associé.

La classe Sql peut hérité de la classe connexion.

Tant que tu n'as pas appelé explicitement la méthode dispose de ton objet connexion cet objet reste en mémoire! Tu peux donc ouvrir et fermer ta connexion sens problème!