Programmation vb.NET multicouche IHM, BPL, DAL, BEL ?

**shurikeNzL** · 30/11/2011, 16h16

Bonjour à tous,

Je me pose des questions concernant la programmation en VB.net, en multicouche. J'ai du mal depuis quelques jours avec ça, donc j'implore votre aide

.

Je dois travailler avec une couche IHM (Interface Homme Machine), une autre BPL (Business Process Layer = Couche métier), la DAL (Data Access Layer) et une dernière la BEL (Business Entity Layer).

Concretement, je n'arrive pas en partant d'un exemple simple, à programmer selon ce modèle d'architecture. Je comprends le plus gros de la théorie (a quoi ça sert, les avantages), mais dans la pratique, c'est une autre histoire.
De plus, la couche BEL reste encore à mes yeux énigmatique : Comment l'utiliser ? Quand l'utiliser ? Pourquoi l'utiliser ?

Je vous propose de m'aider en m'expliquant comment vous programmeriez selon l'architecture cité ci-dessus un exemple tout bête du type :

J'ai une table T_USER, avec les champs ID, Nom, Prenom, Age, et Ville.
Je veux à partir de mon IHM (une winform toute bête avec les champs ID, Nom, ...) ajouter un utilisateur à ma BDD.

Comment m'y prendre pour programmer avec ces couches IHM, BPL, DAL, et BEL ?

Si je m'exprime mal, ou qu'il vous manque des détails pour me répondre, n'hésitez pas à me le faire savoir

.

**bizet** · 01/12/2011, 14h07

Salut

Tu t'exprimes très bien, il n'y a pas de soucis, par contre ton post ressemble beaucoup à "Faites mes devoirs à ma place"...
Peut etre devrais-tu montrer un peu ce que tu as fait, ce sur quoi tu bloques, montrer que tu n'attends pas que l'on te fasse tout.

De plus, la couche BEL reste encore à mes yeux énigmatique : Comment l'utiliser ? Quand l'utiliser ? Pourquoi l'utiliser ?

La couche BEL est la couche qui contient les objets métiers.
Par exemple dans ton cas , elle va contenir la classe "User"

Code :

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

1
2
3
4
5
6
7
8
 
 
public class User {
       public string Id {get;set;}
       public string Nom{get;set;}
       public string Prenom{get;set;}
       public string Age{get;set;}
}

Cette couche est transverse aux 3 autres puisque ton objet métier va se "trimballer" de la couche IHM ou les infos vont être récupérées vers la couche DAL où elles vont être insérées en BDD.

En gros pour ton exemple ca donnerait IHM :

Code :

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

1
2
3
4
5
6
7
8
 
....
User newUser = new User();
newUser.Id = ...
newUser.Nom = ...
 
UserBPL.AddUser(newUser);
.....

Couche BPL

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public class UserBPL{
 
public void AddUser(User newUser)
{
//code permettant par exemple de verifier s'il n'existe pas.
UserDAL.AddUser(newUser);
}
 
}

Couche DAL

Code :

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

1
2
3
4
5
6
7
8
9
 
public class UserDAL{
 
public void AddUser(User newUser)
{
//connexion a la BDD et ajout de l'utilisateur
 
}
}

**shurikeNzL** · 01/12/2011, 15h28

Envoyé par bizet

Salut

Tu t'exprimes très bien, il n'y a pas de soucis, par contre ton post ressemble beaucoup à "Faites mes devoirs à ma place"...
Peut etre devrais-tu montrer un peu ce que tu as fait, ce sur quoi tu bloques, montrer que tu n'attends pas que l'on te fasse tout.

Merci pour ta réponse qui m'aide beaucoup. En faite, je suis apprenti en informatique, il ne s'agit pas là de devoirs, mais uniquement du fait que je suis en entreprise un peu lancé tout seul dans le bain et que je dois comprendre par moi même. Du coup, même si j'ai à peu près réussi à assimiler seul la POO, la programmation en couche me pose problème dans la pratique. J'ai du mal à visualiser comment m'en servir, mais déjà là avec ce que tu m'as expliqué j'imagine mieux la chose.

Je vais tenter de résumer ce que j'ai compris de tes explications, n'hésite pas à me reprendre :

Dans la BEL, on trouve les classes qui nous permettrons d'instancier des objets métiers (mais finalement on y trouve pas les objets en soit ?)

Dans l'IHM, on instancie un objet metier à partir de la classe située dans la BEL, et on prends pour attributs le Nom, Prenom, Age, etc. On vient ensuite appeler des fonctions de la couche inférieure (c'est donc ça finalement le passage d'une couche à l'autre - le fait d'appeler une fonction de la couche inferieure et de lui passer en parametre l'objet métier ?).

Dans la BPL, on a les règles de gestion, tout le code métier. Si tout va bien, qu'on a effectué tout ce qu'on avait à faire, on appelle une fonction se trouvant dans la DAL.

Dans la DAL, j'effectue des requetes parametrées afin d'effectuer les Select, insert et compagnie. Les parametres étant au final les attributs de mon objet métier.

Ok, mais donc au final, peut-être est-ce à cause de l'exemple simpliste, mais j'ai le sentiment que cette couche BEL sert pas à grand chose ?

Bon, mettons que pour l'INSERT c'est ok, dans le sens inverse pour un select, ça se passe comment ? On instancie un objet metier dans la DAL et on remonte ? C'est pas interdit ?

Merci d'avance, je vais tenter de programmer l'INSERT.

**bizet** · 01/12/2011, 16h03

Envoyé par shurikeNzL

Je vais tenter de résumer ce que j'ai compris de tes explications,....

Oui c'est bien ça.

Envoyé par shurikeNzL

Ok, mais donc au final, peut-être est-ce à cause de l'exemple simpliste, mais j'ai le sentiment que cette couche BEL sert pas à grand chose ?

Bien sur que si elle sert. C'est dans cette couche que tu définis tes objets métiers de ton application.
Admettons que tu enleves cette couche, ou est ce que tu définis tes objets métiers comme les Users?

En cherchant des données sur le net, j'ai trouvé un exemple ou effectivement ils n'utilisent pas les concepts de couche BEL puisqu'ils utilisent seulement des DataSets.

Envoyé par shurikeNzL

Bon, mettons que pour l'INSERT c'est ok, dans le sens inverse pour un select, ça se passe comment ? On instancie un objet metier dans la DAL et on remonte ? C'est pas interdit ?

Merci d'avance, je vais tenter de programmer l'INSERT.

Non ce n'est pas interdit.
Comme expliqué précedemment les objets de ta couche BEL sont transverses à tes trois couches.
Ce que tu n'as pas le droit de faire c'est depuis ta couche DAL appelé une fonction de ta couche BPL.

**shurikeNzL** · 01/12/2011, 16h10

Envoyé par bizet

Oui c'est bien ça.

Bien sur que si elle sert. C'est dans cette couche que tu définis tes objets métiers de ton application.
Admettons que tu enleves cette couche, ou est ce que tu définis tes objets métiers comme les Users?

En cherchant des données sur le net, j'ai trouvé un exemple ou effectivement ils n'utilisent pas les concepts de couche BEL puisqu'ils utilisent seulement des DataSets.

Non ce n'est pas interdit.
Comme expliqué précedemment les objets de ta couche BEL sont transverses à tes trois couches.
Ce que tu n'as pas le droit de faire c'est depuis ta couche DAL appelé une fonction de ta couche BPL.

Ecoute, je te remercie, tu m'enlèves une épine du pied. Je poste un peu plus tard du code, si tu as le temps à l'occasion, n'hésite pas à me dire ce que t'en penses. Je met résolu. J'espère que ça pourra servir à d'autre.

EDIT : Si, une chose quand même. Puisque tu n'as pas le droit d'invoquer une fonction d'une couche supérieure, comment remonter l'objet métier jusqu'en haut ?

**bizet** · 01/12/2011, 16h44

Avec une fonction qui retourne un objet!!!

IHM : afficher toutes les infos d'un utilisateur dont on connait son nom :

Code :

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

1
2
3
4
 
string nom =...
 
User monUser = UserBPL.getByName(nom);

BPL

Code :

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

1
2
3
4
5
6
 
public User getByName(string pNom)
{
User monUser = UserDAL.getByName(pNom);
return monUser;
}

DAL

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
public User getByName(string pNom)
{
string requete = "select * ...";
executeReader...
 
User monUser = new User();
User.prenom = resultat[0];
.....
 
return monUser;
}

C'est toujours la couche IHM qui appelle une fonction BPL lui retournant un resultat.
BPL appelle des fonctions de la couche DAL.

**shurikeNzL** · 02/12/2011, 09h13

D'accord très bien. Mais j'ai une autre question maintenant

.
Comment peut-on appeler la méthode d'une classe appartenant à une autre couche sans instancier d'objet de la dite classe ?

Grâce aux interfaces ?

**BenoitM** · 02/12/2011, 09h14

La BEL est partagé par tout le monde

IHM ne connait que la Business Layer et la BEL
Business Layer ne connait que la DAL et BEL
La DAL ne connait que la BEL

**shurikeNzL** · 02/12/2011, 09h21

Envoyé par BenoitM

La BEL est partagé par tout le monde

IHM ne connait que la Business Layer et la BEL
Business Layer ne connait que la DAL et BEL
La DAL ne connait que la BEL

OK pour les réferences, mais une fois que c'est fait, j'ai toujours pas accès aux méthodes de la DAL depuis ma BPL (par exemple).
Il faut bien instancier un objet pour avoir accès aux méthode de la classe qui l'a créé non ?

**BenoitM** · 02/12/2011, 10h12

ben vu que la BPL connait la DAL il n'y a rien qui empeche la BPL d'instancier une classe de la DAL

Il faut bien instancier un objet pour avoir accès aux méthode de la classe

Pas forcément si les méthodes sont déclarées en statique

**shurikeNzL** · 02/12/2011, 10h22

Envoyé par BenoitM

ben vu que la BPL connait la DAL il n'y a rien qui empeche la BPL d'instancier une classe de la DAL

OK, donc mettons que je suis dans la BPL. Etant donné que celle-ci connait la DAL :
- J'instancie un objet DAL qui me permettra d'utiliser la méthode AjouterUtilisateur() de ma classe DAL
- Je passe en parametre de cette fonction mon objet métier de départ.

C'est bien ça ?

**BenoitM** · 02/12/2011, 10h34

oui ton objet BEL va voyager de couche en couche dans les 2 sens

**shurikeNzL** · 02/12/2011, 10h37

Envoyé par BenoitM

oui ton objet BEL va voyager de couche en couche dans les 2 sens

D'accord, je vous remercie tous les deux.

**shurikeNzL** · 02/12/2011, 11h43

Qu'en pensez-vous

?

BEL :

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
Public Class User
 
#Region "Attributs"
    Private mID As Integer
    Private mNOM As String
    Private mPRENOM As String
    Private mAGE As Integer
    Private mVILLE As String
#End Region
 
#Region "Property"
 
    Public Property ID() As Integer
        Get
            Return mID
        End Get
        Set(ByVal value As Integer)
            mID = value
        End Set
    End Property
 
    Public Property NOM() As String
        Get
            Return mNOM
        End Get
        Set(ByVal value As String)
            mNOM = value
        End Set
    End Property
 
    Public Property PRENOM() As String
        Get
            Return mPRENOM
        End Get
        Set(ByVal value As String)
            mPRENOM = value
        End Set
    End Property
 
    Public Property AGE() As Integer
        Get
            Return mAGE
        End Get
        Set(ByVal value As Integer)
            mAGE = value
        End Set
    End Property
 
    Public Property VILLE() As String
        Get
            Return mVILLE
        End Get
        Set(ByVal value As String)
            mVILLE = value
        End Set
    End Property
 
#End Region
 
 
 
    Sub New(ByVal ID As Integer, ByVal NOM As String, ByVal PRENOM As String, ByVal AGE As Integer, ByVal VILLE As String)
        mID = ID
        mNOM = NOM
        mPRENOM = PRENOM
        mAGE = AGE
        mVILLE = VILLE
    End Sub
 
End Class

IHM :

Code :

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

1
2
3
4
5
6
7
8
9
    'Evennement clique BT_AJOUTER -> Instanciation objet métier, envoi à la couche BPL de l'objet metier
    Private Sub BT_AJOUTER_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BT_AJOUTER.Click
 
        Dim NewUser As User = New User(CType(TB_ID.Text, Integer), TB_NOM.Text, TB_PRENOM.Text, CType(TB_AGE.Text, Integer), TB_VILLE.Text)
        Dim UserBPL As New BPL.BPL
        UserBPL.BPLAjouter(NewUser)
 
    End Sub
End Class

BPL :

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 BPL
 
    'Constructeur BPL
    Sub New()
 
    End Sub
 
    'Envoi de l'objet metier à la DAL pour Ajout de l'utilisateur
    Public Sub BPLAjouter(ByVal NewUser As User)
        Dim UserDAL As New DAL.DAL
        UserDAL.DALAjouter(NewUser)
    End Sub
 
    'Envoi de l'objet metier à la DAL pour Suppression de l'utilisateur
    Public Sub BPLSupprimer(ByVal NewUser As User)
        Dim UserDAL As New DAL.DAL
        UserDAL.DALSupprimer(NewUser)
    End Sub
 
End Class

DAL :

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
40
41
42
43
 
Public Class DAL
 
#Region "Constructeurs"
    Sub New()
 
    End Sub
#End Region
 
#Region "Méthodes DAL"
 
    'Insert d'un nouvel User dans la base
    Public Sub DALAjouter(ByVal NewUser As User)
        'Déclaration chaine de connexion & requête SQL paramètrée
        Dim strConnexion As String = "Data Source=xxxxx;Initial Catalog=Formulaire;Integrated Security=SSPI;"
        Dim strRequete As String = "INSERT INTO T_USER (ID, NOM, PRENOM, AGE, VILLE) VALUES (@ID, @NOM, @PRENOM, @AGE, @VILLE)"
 
        'Instanciation des objets Connexion et Commandes
        Dim Connexion As SqlConnection = New SqlConnection(strConnexion)
        Dim Command As SqlCommand = New SqlCommand(strRequete, Connexion)
 
        'Ajout des paramètres à Command
        With Command.Parameters
            .Add("@ID", SqlDbType.Int, 4)
            .Add("@NOM", SqlDbType.NChar, 10)
            .Add("@PRENOM", SqlDbType.NChar, 10)
            .Add("@AGE", SqlDbType.Int, 4)
            .Add("@VILLE", SqlDbType.NChar, 10)
        End With
 
        With Command
            .Parameters("@ID").Value = NewUser.ID
            .Parameters("@NOM").Value = NewUser.NOM
            .Parameters("@PRENOM").Value = NewUser.PRENOM
            .Parameters("@AGE").Value = NewUser.AGE
            .Parameters("@VILLE").Value = NewUser.VILLE
        End With
 
        'Connexion et éxécution
        Connexion.Open()
        Command.ExecuteNonQuery()
        Connexion.Close()
    End Sub

**BenoitM** · 02/12/2011, 11h53

les variables sont en général noté _nom,_prenom
les propriété sont toujours déclarés Nom,Prenom
les paramètres sont écrit avec une miscule au début

Pour la Dal, tu devrais avoir une class DalUser
supprimer DAL devant le nom des fonction DALAjouter-> Ajouter

La connection string pourrait être passer au constructeur de la Dal (ou à chaque méthode) mais elle ne doit surtout pas être en dur

Pour IHM :
On essaye aussi de séparer le Code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Private Sub BT_AJOUTER_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles BT_AJOUTER.Click
 
        AjouterUser(Integer.Parse(tbId.Text), tbNom.Text, TB_PRENOM.Text, Integer.Parse(tbAge.Text), tbVille.Text)        
    End Sub
 
Private Sub AjouterUser(Integer id,String nom, String prenom,Integer Age)
{
        Dim NewUser As User = New User(id,nom,prenom,age)
        Dim UserBPL As New BPL.BPL
        UserBPL.BPLAjouter(NewUser)
End Sub
}

Une petite gestion des exceptions serait le bien venu
1) Pour les Integer.Parse (si l'utilsateur n'a pas encodé un numérique)
2) Pour les problèmes rencontré dans la BPL, DAL

**shurikeNzL** · 02/12/2011, 13h45

Envoyé par BenoitM

les variables sont en général noté _nom,_prenom

OK

Envoyé par BenoitM

les propriété sont toujours déclarés Nom,Prenom

Que veux-tu dire par là ? Tu parles de la mise en forme ?

Envoyé par BenoitM

les paramètres sont écrit avec une miscule au début

OK

Envoyé par BenoitM

Pour la Dal, tu devrais avoir une class DalUser

OK

Envoyé par BenoitM

supprimer DAL devant le nom des fonction DALAjouter-> Ajouter

OK

Envoyé par BenoitM

La connection string pourrait être passer au constructeur de la Dal (ou à chaque méthode) mais elle ne doit surtout pas être en dur

Pour la sécurité j'imagine ?

Code :

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

1
2
3
Sub New(ChaineDeConnexion as String)
       strConnect = ChaineDeConnexion
End Sub

Un truc du genre ?
Mais bon faut bien qu'elle apparaisse en dur quelquepart non ? Comment faire ?

Envoyé par BenoitM

Pour IHM :
On essaye aussi de séparer le Code

OK

Envoyé par BenoitM

Une petite gestion des exceptions serait le bien venu
1) Pour les Integer.Parse (si l'utilsateur n'a pas encodé un numérique)
2) Pour les problèmes rencontré dans la BPL, DAL

OK

**bizet** · 02/12/2011, 14h06

Envoyé par shurikeNzL

Qu'en pensez-vous

?

Que tu as compris et mis en place une architecture N-Tiers. Félicitation.

Envoyé par BenoitM

les variables sont en général noté _nom,_prenom
les propriété sont toujours déclarés Nom,Prenom
les paramètres sont écrit avec une miscule au début

Il s'agit de normes de codages qui ne sont pas obligatoires mais recommandées.

En general on fait :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 Private _nom As String

  
    Public Property Nom() As String
        Get
            Return _nom
        End Get
        Set(ByVal value As String)
            _nom= value
        End Set
    End Property

Pour la DAL, comme le dit Benoit, il y a des améliorations à faire.
Si tu gardes qu'une seule classe DAL, tu vas devoir gérer dedans des Users, mais surement tes autres objets, ta classe va devenir enorme et difficilement lisible.
On conseille donc de faire une classe UserDAL,...

Pour eviter de réécrire la connexion string dans toutes tes fonctions tu peux créer par exemple une classe MainDAL dans laquelle tu ajoutes ta connectionString et dans laquelle tu ouvres la connexion.

Comme ca si tu changes ta connexionString tu le fais à un seul endroit :

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
 
public class MainDAL
{
       public string connectionString ="....";
 
       public void ouvrirConnexionBDD()
       {
...
           connexion.open();
       }
}
 
public class UserDAL : MainDAL
{
          public void createUser(User user)
          {
             ouvrirConnexionBDD();
             ....
           }
}
}

**kheironn** · 02/12/2011, 14h14

Cette architecture est très en vogue en ce moment et utilise des DTO (de ta BEL) Ce sont juste des boites qui ne savent rien faire. Le DOGME de la POO préconise l'emploi de POCO qui ont données + intelligence.

La séparation en 4 couches toujours adulée n'a pas toujours raison d'être. Tu fais 4 dll (c'est souvent la cas) pour rien ? avant de splitter pose toi des questions : ma DAL sera-t-elle utilisée dans une autre appli ? mes DB sont-elles interchangeables ? (= mon appli peut tourner avec oracle, sqlserv, etc. en parallèle) Si les réponses sont non, alors DAL et BL n'ont pas besoin de former 2 dll distincts. Mes entités sont elle utilisables ailleurs ? si non alors ...
Et ainsi de suite.

Au final tu peux très bien regrouper tout ça dans une seule dll, quitte à y créer des répertoires. J'ai déjà vue de nombreuses application stand-alone découpées en 4 dll qui ne sont jamais réutilisées car trop spécifiques.
Nombreuses sont les appli qui pourraient tournée avec des POCO et une seule couche BL+BEL+DAL qui utilise une dll 'tools' capable de gérer les connexions db et autres spécificités de la persistance. Ton POCO possède une méthode save et une méthode load (ou plusieurs selon les besoins) qui appellent les traitements qui vont bien... il peuvent tout à fait faire appelle à une DAL externe s'il y a des risques de changer de sgbd... Mais, franchement, je travaille actuellement pour une grande boite néerlandaise avec Oracle, et il n'est pas question de passer à SQLServer... de plus il faudrait refaire toutes les SP !

Pour conclure le découpage 4-tiers est utile dans certains cas. Des cas d'école pour apprendre, des cas de réutilisation des couches dans une suite de logiciels par exemple, mais pas juste pour faire jolie. Organiser sont code ne signifie pas le découper en vain. Rien n'empêche cependant de faire un découpage pour séparer des traitements et les rendre plus facile à retrouver sans pour autant faire une tripoté de dll.
Comme je le disais faire 4 dll signifie un besoin de réutilisation +/- universelle et d'interchangeabilité. 4 répertoires peuvent exister dans une dll si ce besoin n'existe pas.

ATTENTION, je ne contre-dis en rien ce qui précède. C'est tout à fait juste, je ne fais que donner une opinion sur l'utilité de la chose. Le rôle d'un architecte logiciel est justement de comprendre ces découpages et de savoir s'ils sont judicieux. de savoir comment organiser son application et comment elle s'intègre dans l'ensemble du client/de la DSI.

**shurikeNzL** · 02/12/2011, 14h15

Envoyé par bizet

Que tu as compris et mis en place une architecture N-Tiers. Félicitation.

Là tu me fais plaisir !

Envoyé par bizet

Pour la DAL, comme le dit Benoit, il y a des améliorations à faire.
Si tu gardes qu'une seule classe DAL, tu vas devoir gérer dedans des Users, mais surement tes autres objets, ta classe va devenir enorme et difficilement lisible.
On conseille donc de faire une classe UserDAL,...

De ce que j'ai compris, on peut avoir plusieurs DAL, mais finalement on considère qu'elle font toute parties de la couche d'accès aux données. C'est juste une division de la couche DAL manière d'aéré le code etc.

Envoyé par bizet

Pour eviter de réécrire la connexion string dans toutes tes fonctions tu peux créer par exemple une classe MainDAL dans laquelle tu ajoutes ta connectionString et dans laquelle tu ouvres la connexion.

Comme ca si tu changes ta connexionString tu le fais à un seul endroit

OK, je vois maintenant !

Ecoutez merci à tous les deux, vous m'avez bien fait avancer en deux jours.

**shurikeNzL** · 02/12/2011, 14h19

Envoyé par kheironn

Cette architecture est très en vogue en ce moment et utilise des DTO (de ta BEL) Ce sont juste des boites qui ne savent rien faire. Le DOGME de la POO préconise l'emploi de POCO qui ont données + intelligence.

La séparation en 4 couches toujours adulée n'a pas toujours raison d'être. Tu fais 4 dll (c'est souvent la cas) pour rien ? avant de splitter pose toi des questions : ma DAL sera-t-elle utilisée dans une autre appli ? mes DB sont-elles interchangeables ? (= mon appli peut tourner avec oracle, sqlserv, etc. en parallèle) Si les réponses sont non, alors DAL et BL n'ont pas besoin de former 2 dll distincts. Mes entités sont elle utilisables ailleurs ? si non alors ...
Et ainsi de suite.

Au final tu peux très bien regrouper tout ça dans une seule dll, quitte à y créer des répertoires. J'ai déjà vue de nombreuses application stand-alone découpées en 4 dll qui ne sont jamais réutilisées car trop spécifiques.
Nombreuses sont les appli qui pourraient tournée avec des POCO et une seule couche BL+BEL+DAL qui utilise une dll 'tools' capable de gérer les connexions db et autres spécificités de la persistance. Ton POCO possède une méthode save et une méthode load (ou plusieurs selon les besoins) qui appellent les traitements qui vont bien... il peuvent tout à fait faire appelle à une DAL externe s'il y a des risques de changer de sgbd... Mais, franchement, je travaille actuellement pour une grande boite néerlandaise avec Oracle, et il n'est pas question de passer à SQLServer... de plus il faudrait refaire toutes les SP !

Pour conclure le découpage 4-tiers est utile dans certains cas. Des cas d'école pour apprendre, des cas de réutilisation des couches dans une suite de logiciels par exemple, mais pas juste pour faire jolie. Organiser sont code ne signifie pas le découper en vain. Rien n'empêche cependant de faire un découpage pour séparer des traitements et les rendre plus facile à retrouver sans pour autant faire une tripoté de dll.
Comme je le disais faire 4 dll signifie un besoin de réutilisation +/- universelle et d'interchangeabilité. 4 répertoires peuvent exister dans une dll si ce besoin n'existe pas.

ATTENTION, je ne contre-dis en rien ce qui précède. C'est tout à fait juste, je ne fais que donner une opinion sur l'utilité de la chose. Le rôle d'un architecte logiciel est justement de comprendre ces découpages et de savoir s'ils sont judicieux. de savoir comment organiser son application et comment elle s'intègre dans l'ensemble du client/de la DSI.

Moi tu sais, on m'impose cette architecture alors j'éxécute, après est-ce que je suis pour ou contre, je ne pense pas pouvoir me prononcer vu mon faible niveau en programmation

.

Programmation vb.NET multicouche IHM, BPL, DAL, BEL ? [Débutant]

VB.NET

Discussions similaires

Partager

Partager