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

Version imprimable

Voir 40 message(s) de cette discussion en une page

30/11/2011, 16h16
shurikeNzL

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 :zoubi:.

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 ;).
01/12/2011, 14h07
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.

Citation:

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:

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:

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

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:

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 } }
01/12/2011, 15h28
shurikeNzL

Citation:

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.
01/12/2011, 16h03
bizet

Citation:

Envoyé par shurikeNzL

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

Oui c'est bien ça.

Citation:

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.

Citation:

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.
01/12/2011, 16h10
shurikeNzL

Citation:

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 ?

Avec une fonction qui retourne un objet!!!

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

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

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

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.

02/12/2011, 09h13
shurikeNzL

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 ?
02/12/2011, 09h14
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
02/12/2011, 09h21
shurikeNzL

Citation:

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 ? :calim2:
02/12/2011, 10h12
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

Citation:

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
02/12/2011, 10h22
shurikeNzL

Citation:

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 ?
02/12/2011, 10h34
BenoitM

oui ton objet BEL va voyager de couche en couche dans les 2 sens
02/12/2011, 10h37
shurikeNzL

Citation:

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. :ccool:

Qu'en pensez-vous :oops: ?

BEL :

Code:

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:

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:

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:

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

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:

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

02/12/2011, 13h45
shurikeNzL
Citation:

Envoyé par BenoitM

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

OK

Citation:

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 ?

Citation:

Envoyé par BenoitM

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

OK

Citation:

Envoyé par BenoitM

Pour la Dal, tu devrais avoir une class DalUser

OK

Citation:

Envoyé par BenoitM

supprimer DAL devant le nom des fonction DALAjouter-> Ajouter

OK

Citation:

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:

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 ?

Citation:

Envoyé par BenoitM

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

OK

Citation:

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

Citation:

Envoyé par shurikeNzL

Qu'en pensez-vous :oops: ?

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

Citation:

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:

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:

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(); .... } } }

02/12/2011, 14h14
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.
02/12/2011, 14h15
shurikeNzL

Citation:

Envoyé par bizet

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

Là tu me fais plaisir ! :P

Citation:

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.

Citation:

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.
02/12/2011, 14h19
shurikeNzL

Citation:

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 :zoubi:.

Dans les recommandation de codage les propriétés elles sont nottés en CamelCase

Pour la dal je pense à un truc du genre
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 Public Class DalUser { private _connectionString #Region "Constructeurs" Sub New(connectionString As String) { _connectionString = connectionString; } End Sub #End Region
L'idée de faire une classe principale, et des classes dérivés n'est pas mal non plus

02/12/2011, 14h34
BenoitM

Citation:

Envoyé par kheironn

...

Tu peux très découper ton programme en couche en faisait des repertoires différents et sans utiliser de dll mais je ne vois pas ce que ca apporte de vouloir éviter 3 dll...

De plus même si tu ne changes jamais de bd, d'IHM, le modèle en couche permet d'implémenter plus rapidement un changement, d'implémenter de nouvelles règles à l'endroit le plus approprier

Citation:
Envoyé par BenoitM
Dans les recommandation de codage les propriétés elles sont nottés en CamelCase

Pour la dal je pense à un truc du genre
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 Public Class DalUser { private _connectionString #Region "Constructeurs" Sub New(connectionString As String) { _connectionString = connectionString; } End Sub #End Region
L'idée de faire une classe principale, et des classes dérivés n'est pas mal non plus
Quelque chose reste flou pour moi :

Si on écrit ce code, il va bien falloir instancier un objet DALUser avec en paramètre la chaine de connexion non ? C'est pas grave dans ce cas ? Là c'est plus écrit "en dur" ?
Au passage, que signifie de manière concrete "en dur" ? :mouarf:

02/12/2011, 14h42
BenoitM

On appelle codé en dur (hardcodé)(HardCoding) quand une variable est écrite dans le code
(cf variable static, toutes déclaration de chaine de caractère "toto")
Et donc pour changer la valeur de cette variable tu dois recompiler le code.

Il y a 2 problèmes avec ta technique.
1) Tu écrits en dur 25 fois la même chaine de connection. Le nom de serveur change. tu dois aller modifier 25 endroit en esperant ne pas en oublier un, ne pas avoir fait une faute de frappe dans un des 25 endroits
2) Ta chaine de connection est écrit en dur, et donc tu dois recompiler le programme si tu dois changer la connection string

Pour eviter de coder en dur, on utilise l'AppConfig, ainsi si tu dois modifier le nom du serveur il suffit d'éditer le fichier de configuration avec un notepad

De plus la DAL permet l'access au donnée mais elle n'a pas besoin de savoir où sont stocker les données.
02/12/2011, 14h50
shurikeNzL

Citation:

Envoyé par BenoitM

On appelle codé en dur quand une variable est écrite dans le code
(cf variable static, toutes déclaration de chaine de caractère "toto")
Et donc pour changer la valeur de cette variable tu dois recompiler le code.

Il y a 2 problèmes avec ta technique.
1) Tu écrits en dur 25 fois la même chaine de connection. Le nom de serveur change. tu dois aller modifier 25 endroit en esperant ne pas en oublier un, ne pas avoir fait une faute de frappe dans un des 25 endroits
2) Ta chaine de connection est écrit en dur, et donc tu dois recompiler le programme si tu dois changer la connection string

Pour eviter de coder en dur, on utilise l'AppConfig, ainsi si tu dois modifier le nom du serveur il suffit d'éditer le fichier de configuration avec un notepad

De plus la DAL permet l'access au donnée mais elle n'a pas besoin de savoir où sont stocker les données.

OK, j'ai compris. Je vais me pencher sur l'AppConfig. Thank's !
05/12/2011, 10h14
kheironn

Citation:

Envoyé par shurikeNzL

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 :zoubi:.

Je l'ai bien compris.

comme je le disais, c'est très à la mode cette façon de faire. Il y a une tendance à l'uniformisation des façons de faire et penser.

Comme toujours, celui qui te donne ton travail à toujours raison ;)
Tu devrais demander pourquoi on t'impose cette architecture, ce qu'elle t'apporte...
Tu devrais avoir une réponse du genre : "séparer les traitements et les responsabilités dans le but d'interchangeabilité des couches (d'où plusieurs dll)".
05/12/2011, 14h14
kheironn

Citation:

Envoyé par BenoitM

Tu peux très découper ton programme en couche en faisait des repertoires différents et sans utiliser de dll mais je ne vois pas ce que ca apporte de vouloir éviter 3 dll...

C'est bien ce qui je disais, il y a un formatage des développeurs...
La séparation des couches en dll doit avoir une raison technique d'être. Dans un framework comme .Net, c'est tout à fait évident ; sinon, nos projets n'auraient qu'une référence à .Net et basta. Dans un projet de gestion bidon comme on en fait tant, cela se discute plus. Le découpage en dll est là pour pouvoir utiliser un fonctionnement modulaire et pour réutiliser ce qui est fait, selon les besoins d'un ENSEMBLE d'applications. (pour plus d'info voir un urbaniste info). Si ton appli est stand-alone, inutile de le faire; sauf dans le cas éventuel d'une future évolution qui ne viendra jamais puisque la fin du monde est pour 2112 :P
Les choses ne doivent pas être faites parce que c'est joli et que tous les ânes les font, mais parce qu'IL Y A UNE RAISON, UN BESOIN !
Maintenant, je le répète, il faut voir l'ensemble des choses ! C'est ça le taf de l'architecte !

Citation:

Envoyé par BenoitM

De plus même si tu ne changes jamais de bd, d'IHM, le modèle en couche permet d'implémenter plus rapidement un changement, d'implémenter de nouvelles règles à l'endroit le plus approprier

Tu confonds dll et couche. Comme je le disais, tu peux avoir 250 couches dans une seule dll.
Ensuite, le découpage en couches peut finir par être plus lourd qu'autre chose. Tu as une DAL, une BL, des DTO et une IHM. Pour certaines modifs, tu vas toucher - contrairement à ce que tu dis - à QUATRE emplacements (voir plus) afin de les faire. N-tiers N'EST PAS la seule architecture valable ! Elle contredit même les canons POO qui préconisent des objets complets, comme les POCO, qui ont données et intelligence. Ces derniers regroupent donc BL et EL voir DAL s'ils ne sont pas "Persist Ignore".
Personnellement, j'aime bien avoir des objets de ce type qui ont des tas de méthodes pour travailler. Ils ont souvent les méthodes save et load qui vont bien et font appel à une classe (issus d'une autre dll pour le coup) qui sait gérer les db grâce aux classes DB... de .Net, ancêtre de Sql..., Oracle..., etc. et à une reconnaissance du provider de ma db. Je passe à cette classe le nom de la sp ou le sql de la requête, les paramètres, et hop, ça roule.

Pour conclure, je ne dis pas que cette archi CLASSIQUE n-tiers est mauvaise. J'explique qu'elle est au centre du formatage des jeunes générations de développeurs qui ont pour dogme ce mode de pensée. Selon les besoins je l'utilise aussi.

il faudrait que je retrouve l'article qui explique tout ça, histoire de vous faire comprendre d'où je tire mes arguments... :mouarf:
05/12/2011, 15h47
ShaiLeTroll

Attention au "francisation" des termes !

IHM (Interface Homme Machine) -> user interface (UI).
BPL (Business Process Layer) -> Business Logic Layer (BLL)
BEL (Business Entity Layer) -> Business Logic Layer (BLL)
DAL (Data Access Layer) ok

Rappelons qu'un objet à pour but de regrouper données et méthodes !
Architecturer son code est important, j'ai eu beaucoup de collègue qui avait du mal à comprendre les notions de "responsabilité d'une classe" qui détermine quelles méthodes vont dans quelle classe !
Et la dessus, on peut rapidement faire n'importe quoi !

Dans ton exemple de code, la Séparation BPL et BEL n'est pas liée à une architecture par couche mais plutôt un pseudo-modèle MVC, le BPL servant de Controller entre la BEL (Modèle) et l'IHM (Vue)

L'amalgame entre ces deux concepts architecturaux est fréquent !
Comme souvent le MVC s'articule autour d'un modèle muliti-couche, cela se comprend, mais c'est fait oublier que le MCV est avant tout un ensemble de Pattern permettant de mieux gérer ses couches !

Surtout qu'il ne faut pas forcément globalisé le MVC et N-Tiers, on peut trouver des chaques couche des mini-couches, en fonction du point vue que l'on prend, on peut aussi considérer l'architecture d'un progiciel de différentes manière

j'ai participé à une application Web (un générateur d'application à base de XML, à la limite d'être un FrameWork), l'ensemble du projet était multi-couche, les basiques IHM (Browser), BEL (POO en PHP), Zend pour le FrameWork DAL

Mais chaque couche pouvait être considérée un module lui-même divisé en couche
IHM => HTML pour la présentation, un modèle objet codé en JS\AJAX, le DAL étant le serveur web echangeant des objets JSON (effectivement pour le client, la partie serveur pouvaient s’apparenter à un SGBD par sa structure et sa conception)
Je peux te dire que mon collègue de l'époque c'était laché sur le JS, il avait conçu un modèle objet encapsulant les objets JSON, la partie cliente sur ce coup là était très riche en terme d'architecture (cela pour répondre à des fonctionnalité très avancées complètement configurable)

Pour la partie PHP, idem, il y a le BEL en PHP mais pour lui la présentation c'est plus que de l'IHM avec un Browser, les WebService ou Import\Export de Fichier étaient aussi considérés comme des Vues\Controller, au lieu de présenter du HTML+AJAX, cela générait du SOAP, REST, CSV, XML ... des vues de différents formats !

Une architecture par couche sans appliquer de design-pattern n'a pas un grand intérêt car au final, soit la séparation Vue-Modèle devient trop faible (par facilité) ou alors devient inutilement alambiqué à cause de mauvaise inter-dépendance entre les couches !

Souvent la vue (IHM) n'est qu'une coquille vide avec un ensemble de listener\event handler qui fait appel au pseudo-Controller (BPL) pour manipuler les entités (sans le faire directement)
Dans le cas d'une IHM client lourd, très vite, la facilité fait que l'on utilise directement la BEL, surtout si il n'y a pas un fort besoin d'avoir des présentations multiples.

BPLAjouter, BPLSupprimer, doivent-elle être en dehors de l'objet user ?
Quelle est la raison de mettre ces fonctions en dehors ?
Tu peux instancier un objet, ce dernier fourni une méthode Save et se sérialize
Idem, tu peux très bien avoir une méthode Delete dans l'objet, et il supprime de la DB via le DAL

Tu peux très bien faire une classe User qui gère un seul user
Souvent dans les modèle MVC comme Rails, implicitement Users est une collection de User ...:roll:
Du coup, Users est-il du BEL ou BPL, dans ton code en exemple c'est du BPL ...
Le modèle est donc réparti dans User (BEL) et Users (BPL), n'est-ce pas maladroit ?

Il existe en Java, PHP, Delphi des FrameWork d'Objet Persistant, c'est souvent l'objet qui gère sa propre lecture\écriture\suppression (via les objets du FrameWork par héritage, composition ou délégation)

La Notion de FrameWork est très important, certains imposent une philosophie particulière interprétant les concepts de POO et Pattern un peu librement !
Il est difficile d'avoir une réponse à absolue à ce type de problème, car le FrameWork et le langage influence la méthode de travail !

Pour VB.NET, il y a le FrameWork .NET certe, mais je parle surtout du FrameWork de ta société, leur propre architecture, souvent c'est plus une bibliothèque d'objet fait pour tel et tel besoin qui manque de cohérence
Vu qu'ils t'imposent une séparation multi-couche, c'est qu'ils ont déjà conçu des applications avec ces méthodes, c'est curieux que n'ait pas déjà un FrameWork interne sur lequel te greffer !
05/12/2011, 16h00
BenoitM

Citation:

Envoyé par kheironn

Ensuite, le découpage en couches peut finir par être plus lourd qu'autre chose. Tu as une DAL, une BL, des DTO et une IHM. Pour certaines modifs, tu vas toucher - contrairement à ce que tu dis - à QUATRE emplacements (voir plus) afin de les faire. N-tiers N'EST PAS la seule architecture valable ! Elle contredit même les canons POO qui préconisent des objets complets, comme les POCO, qui ont données et intelligence. Ces derniers regroupent donc BL et EL voir DAL s'ils ne sont pas "Persist Ignore".
Personnellement, j'aime bien avoir des objets de ce type qui ont des tas de méthodes pour travailler. Ils ont souvent les méthodes save et load qui vont bien et font appel à une classe (issus d'une autre dll pour le coup) qui sait gérer les db grâce aux classes DB... de .Net, ancêtre de Sql..., Oracle..., etc. et à une reconnaissance du provider de ma db. Je passe à cette classe le nom de la sp ou le sql de la requête, les paramètres, et hop, ça roule.

Si j'ai une règle business "Prix ne peut pas etre supérieur à 1000€" je n'aurai qu'un endroit à changer
Si j'ajoute un paramètre à ma fonction, je devrais peut-être changer mes 4 couches mais au moins je n'oublierai pas dans l'écran X d'ajouter ce paramètre car mes écrans définissent plusieurs fois le même comportement

Je ne pense pas que le modèle en couche interdit le POCO et vice versa.
Certaines règles ne sont pas définisable dans le POCO. Exemple un client X ne peut acheter pour plus de Y €

Et le POCO n'interdit pas d'avoir un modèle en couche pour Sauver les donner.
Ce n'est pas parce que ton objet Etudiant contient Save() que tu es obliger de definir la requete dans cette méthode
05/12/2011, 16h04
ShaiLeTroll

Sans parler des contraintes\CHECK fourni par la DB !

Beaucoup d'application déportent l'intelligence du modèle dans les Triggers\SP de la DB !
niveau conception disons que :vomi:
mais niveau performance :zekill:
La dessus, il faut être réaliste, la généricité ou la [in]perfection du code, cela à un coût, il faut savoir faire des compromis sans être non plus trop dans le "on the fly"

SQL Server ou Oracle fournissent tant de possibilité à ce sujet, que cela déborde très souvent ! Au final, la couche métier ne se résume qu'à un appel de procédure !

Normalement, en modèle en couche, on a pas besoin de modifier toutes les couches, si tu rajoutes une nouvelle règle de gestion, la modification dans la BEL suffit, une petite exception refusant le Save remontant qu'à la vue ... et le tour est joué !

Citation:

Certaines règles ne sont pas définisable dans le POCO. Exemple un client X ne peut acheter pour plus de Y €

Tout dépend comment tu le modélise !

Est-ce client qui achète ou est-ce une commande que l'on facture tout en vérifiant que la disponibilité en stock et le crédit du compte client !

Citation:

Envoyé par BenoitM

Et le POCO n'interdit pas d'avoir un modèle en couche pour Sauver les donner.
Ce n'est pas parce que ton objet Etudiant contient Save() que tu es obliger de definir la requete dans cette méthode

Je dirais même qu'il ne devrait pas y avoir des SQL dans la méthode Save, cette dernière doit passer l'objet à un sérialisateur (celui pouvant être DB, Fichier XML, ...), le sérialisateur ne connait pas l'objet et l'utilise de façon purement générique via la Reflexion (RTTI) qui fournisse les propriétés sérializables, les clés de mise à jour, les contraintes, les relations, les objets devant être implicite mis à jour au passage ...

Encore une fois, tout dépend du choix de Framework de Persistance !
06/12/2011, 16h06
shurikeNzL

Citation:

Envoyé par shurikeNzL

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 ?

OK, ça c'est fait.
Mais maintenant, mettons qu'on utilise une interface WinForm quelque peu différente :
Un datagridview pour afficher les colonnes de notre table excepté ID.

Si je veux supprimer un enregistrement dans la table de la BDD en se basant sur l'ID à partir d'un bouton supprimer, comment faire ?

En clair, je suis l'utilisateur du programme, j'ai ma fenetre avec un joli datagridview qui m'affiche les enregistrements de la table. Je selectionne une ligne, et clique sur supprimer.

Comment mon programme fait-il la liaison entre la ligne que j'ai selectionné et la ligne qu'il doit supprimer dans la BDD ?
06/12/2011, 16h59
Maniz

Je ne m'y connais pas trop en couche, donc je ne sais pas ou placer le code dans ton cas. Mais personnelement je met une colonne "Identifiant" dans mes datagridview mais non visible.

Code:

Me.DGV.Columns("Ma Colonne").Visible = False

Ainsi, tu as accé à l'identifiant sans l'afficher à l'utilisateur, à voir si il n'y a pas mieux :p
07/12/2011, 08h39
shurikeNzL

Citation:

Envoyé par Maniz

Je ne m'y connais pas trop en couche, donc je ne sais pas ou placer le code dans ton cas. Mais personnelement je met une colonne "Identifiant" dans mes datagridview mais non visible.

Code:

Me.DGV.Columns("Ma Colonne").Visible = False

Ainsi, tu as accé à l'identifiant sans l'afficher à l'utilisateur, à voir si il n'y a pas mieux :p

Je pense que je vais être forcé de faire ça vu que je ne vois pas comment faire autrement ^^.

Mais je me demande si au lieu d'amener ma datasource direct dans le datagridview s'il ne serait pas possible d'amener une liste d'objet User dans mon datagridview. Ca se fait ça ?

Oui oui, tu peux faire cela.

Perso, j'me suis mis à la programmation en couche y a pas longtemps non plus et j'ai ceci dans la ma couche DAL par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Public Function GetUsersByName(ByVal name As String) As List(Of User) users = New List(Of User) ConnectDB() sql = 'la requête qui va bien ds = Cnx.DoSelect(sql) If ds.Tables.Count > 0 Then For Each row As DataRow In ds.Tables(0).Rows users.Add(New User("les arguments qui vont bien")) Next End If DisconnectDB() Return users End Function
Je récupère donc bien une liste d'objets de type User et j'affecte cette liste à la propriété Datasource de mon Datagridview.

Sinon, j'aimerais profiter de ce topic pour m'assurer d'avoir bien compris le bazar (c'est nouveau pour moi aussi).

Dans la couche BEL, j'ai mis les différents objets métier dont l'application a besoin.
Dans la couche DAL, j'ai les fonctions d'accès DB qui retourne les objets de la BEL.
Dans la couche BLL, j'ai les fonctions qui seront utilisées par la couche graphique pour avoir accès aux objets métiers.

Est-ce juste jusque là ?

Du coup, je m'interroge sur un truc. Dans une de mes classes d'objets, je fais appel à une fonction de la couche DAL. Est-ce correct ? Si non, où cet appel est-il sensé se faire ? Je ne donne pas d'exemple concret volontairement car j'aimerais connaître la réponse "théorique" (ce qui devrait être fait idéalement).

Merci d'avance,

Griftou.

EDIT : Je crois que je viens de comprendre. Je pense que ça doit aller dans la couche BLL mais j'attends tout même la confirmation de personnes avec plsu d'XP dans le domaine ^^

07/12/2011, 10h55
shurikeNzL

Citation:

Envoyé par griftou

Dans une de mes classes d'objets, je fais appel à une fonction de la couche DAL. Est-ce correct ?

J'ai pas plus d'experience que toi, mais il me semble que que déjà à la base, la BEL ne référence aucune couche et que donc il est normalement impossible d'appeler une fonction de l'IHM, BLL ou DAL.

IHM référence la BPL et la BEL
BPL référence la DAL et la BEL
DAL référence la BEL uniquement.
BEL ne référence aucune couche sinon on aurait un problème de référence circulaire.

Que l'on me corrige si je dis faux.
07/12/2011, 11h00
kheironn

Oui, c'est ça dans le cas de cette architecture 4 couches.

Citation:

Envoyé par BenoitM

Si j'ajoute un paramètre à ma fonction, je devrais peut-être changer mes 4 couches

Je pensais entre autre à ce type de modif en parlant de devoir changer à x endroits...

Mais j'insiste, le découpage en couche est une architecture parmi d'autres. Une série de pattern qu'il faut connaitre et respecter pour ne pas tomber dans les antipatterns si coûteux. (Mon préféré étant le spaghetti.

Ce qu'il faut c'est avoir une architecture adaptée au besoins réelles et ne pas faire du N-tiers parce que c'est joli !

D'ailleurs les deux derniers projets sur lesquels j'ai travaillé étaient découpés en dll fonctionnelles s'appuyant sur des dll de framework, etc... 64 dll dans un projet ne signifie pas 64 couches ! Il y avait 2 DAL, 2 IHM, des batch, et des tas de dll métier/framework

Je vais quand même donner un exemple concret pcq j'ai du mal :oops:.

Hop, un peu de code pour commencer :

Code:

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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
Imports System.ComponentModel
 
Public Class Parties
    Inherits List(Of Partie)
 
    Implements INotifyPropertyChanged
    Public Event PropertyChanged(ByVal sender As Object, ByVal e As System.ComponentModel.PropertyChangedEventArgs) Implements System.ComponentModel.INotifyPropertyChanged.PropertyChanged
 
    Private Sub NotifyPropertyChanged(ByVal info As String)
        RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(info))
    End Sub
 
    Public Overloads Sub Add(ByVal partie As Partie)
        MyBase.Add(partie)
        NotifyPropertyChanged("ListParties")
    End Sub
 
    Public Overloads Function Find(ByVal id As Integer) As Partie
        For Each elem As Partie In Me
            If elem.Id = id Then
                Return elem
            End If
        Next
        Return Nothing
    End Function
 
    'Public Overloads Function Remove(ByVal partie As Partie) As Boolean
    '    If Not DAL_Partie.DeletePartie(partie) Then
    '        Throw New Exception("Impossible de supprimer cette partie")
    '        Return False
    '    Else
    '        Return MyBase.Remove(partie)
    '    End If
    'End Function
 
End Class
 
Public Class Partie
    Implements IComparable(Of Partie)
    Protected Function CompareTo(ByVal other As Partie) As Integer _
      Implements IComparable(Of Partie).CompareTo
        If TypeOf other Is Partie Then
            Dim temp As Partie = CType(other, Partie)
            Return Me.ordre.CompareTo(temp.Ordre)
        End If
 
        Throw New ArgumentException("L'objet n'est pas d'un type valide.")
    End Function
 
    Private _id As Integer
    Public Property Id As Integer
        Set(value As Integer)
            _id = value
            Me.Status = e_status.Updated
        End Set
        Get
            Return _id
        End Get
    End Property
 
    Private _ordre As Integer
    Public Property Ordre As Integer
        Set(value As Integer)
            _ordre = value
            Me.Status = e_status.Updated
        End Set
        Get
            Return _ordre
        End Get
    End Property
 
    Private _textes As Textes
    Public Property Textes As Textes
        Set(value As Textes)
            _textes = value
            Me.Status = e_status.Updated
        End Set
        Get
            Return _textes
        End Get
    End Property
 
    Public Property Status As e_status
    Public Enum e_status As Integer
        UpToDate = 1
        Created = 2
        Updated = 3
    End Enum
 
 
    Public Sub New(ByVal id As Integer, ByVal ordre As Integer, ByVal textes As Textes) 'ByVal nom As String
        Me.Id = id
        Me.Ordre = ordre
        Me.Textes = textes
        Me.Status = e_status.UpToDate
    End Sub
 
    Public Sub New(ByVal ordre As Integer, ByVal textes As Textes) 'ByVal nom As String
        Me.Ordre = ordre
        Me.Textes = textes
        Me.Id = 0
        Me.Status = e_status.Created
    End Sub
 
End Class

Ma question portait donc sur la portion de code en commentaire.
Me rendant compte qu'il me manque donc une couche pour faire les choses "correctement", j'ai créé ceci :

Code:

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
Public Class BLL_Partie
 
    Public Shared Function GetPartieById(ByVal id As Integer) As Partie
        Return DAL_Partie.GetPartieById(id)
    End Function
 
    Public Shared Function GetAllParties() As Parties
        Return DAL_Partie.GetAllParties
    End Function
 
    Public Shared Function UpdatePartie(ByVal partie As Partie) As Boolean
        Return DAL_Partie.UpdatePartie(partie)
    End Function
 
    Public Shared Function DeletePartie(ByVal partie As Partie) As Boolean
        Return DAL_Partie.DeletePartie(partie)
    End Function
 
    Public Shared Function NewPartie(ByVal partie As Partie) As Boolean
        Return DAL_Partie.NewPartie(partie)
    End Function
 
    Public Shared Function CommitUpdates(ByVal parties As Parties) As Boolean
        Dim result As Boolean = False
        Dim ordre As Integer = 0
        For Each elem As Partie In parties
            If elem.Ordre = ordre Then
                Throw New Exception("Chaque partie doit avoir un numéro d'ordre unique.")
                Return result
            Else
                ordre = elem.Ordre
            End If
        Next
        For Each partie As Partie In parties
            Select Case partie.Status
                Case Global.Evolution.Partie.e_status.Updated
                    If DAL_Partie.UpdatePartie(partie) Then
                        partie.Status = Global.Evolution.Partie.e_status.UpToDate
                    Else
                        Throw New Exception("Partie avec l'id " & partie.Id.ToString & " non mise à jour.")
                    End If
 
                Case Global.Evolution.Partie.e_status.Created
                    If DAL_Partie.NewPartie(partie) Then
                        partie.Status = Global.Evolution.Partie.e_status.UpToDate
                    Else
                        Throw New Exception("Partie avec le texte FR """ & partie.Textes.Find(2).Texte & """ non crée.")
                    End If
            End Select
        Next
        Return result
    End Function
 
    Public Shared Function Remove(ByVal partie As Partie) As Boolean
        If Not DAL_Partie.DeletePartie(partie) Then
            Throw New Exception("Impossible de supprimer cette partie")
            Return False
        Else
            Return Parties.Remove(partie) 'le problème est sur cette ligne...
        End If
    End Function
End Class

N.B. : Avant, les appels à la couche DAL se passaient directement dans l'évènement des contrôles graphiques :aie:.

Seulement je cale sur le fonction Remove (la dernière). Lorsque sur l'interface, l'utilisateur choisit une partie dans la liste qui lui est affichée et qu'il clique sur le bouton supprimer, je souhaite donc faire appel à cette fonction. Elle même fera donc appel à la fonction DeletePartie se trouvant dans la couche DAL mais ensuite, il faut que je retire la partie choisie par l'utilisateur de la liste.
Le problème est que je n'ai pas accès à l'objet parties depuis la couche BLL (aussi appelée BPL si j'ai suivi). Je pourrais éventuellement passé cet objet en paramètre de la fonction mais je ne trouve pas ça élégant ^^

Que feriez-vous à ma place ?

Griftou.

Citation:

Envoyé par griftou

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
Public Function GetUsersByName(ByVal name As String) As List(Of User)
        users = New List(Of User)
        ConnectDB()
 
        sql = 'la requête qui va bien
        ds = Cnx.DoSelect(sql)
        If ds.Tables.Count > 0 Then
            For Each row As DataRow In ds.Tables(0).Rows
                users.Add(New User("les arguments qui vont bien"))
            Next
        End If
        DisconnectDB()
 
        Return users
    End Function

Dis moi, la variable ds est de quel type ? et quel est le rôle de Cnx et son type ? Merci :P.

Pas facile la prog en couche :aie:.

07/12/2011, 13h24
Kropernic

Citation:

Envoyé par shurikeNzL

Dis moi, la variable ds est de quel type ? et quel est le rôle de Cnx et son type ? Merci :P.

Pas facile la prog en couche :aie:.

Pour ds, c'est un dataset.

Pour Cnx, c'est plus compliqué ^^.
En fait, au tout début que j'ai commencé le .NET (sur VS2003 à l'époque), je galérais sévère avec les accès DB.

Alors quand j'ai eu réussi à faire qqch qui tourne, j'en ai fait une dll à laquelle je passe qqes paramètres pour pouvoir me connecter la db et faire des requêtes.

Cnx est une instance de cette dll (j'espère que j'utilise le bon vocalaire). Cnx est mon abréviation de connexion en fait.

Si tu le souhaite, je peux te filer les sources de cette dll mais je doute que ce soit une bonne idée. C'est vraiment un truc mal foutu que je vais m'atteler à rendre plus propre dans pas longtemps (j'ai une formation prévue en décembre, ça va aider^^). Par exemple, je n'utilise aucune requête paramétrée. Bref, c'est casse gueule. Mais bon, dans mon environnement, je n'ai pas besoin de qqch de plus perfectionné. Par contre, je ne la recommanderais pas pour qqn d'autre.
07/12/2011, 13h47
shurikeNzL

Citation:

Envoyé par griftou

Si tu le souhaite, je peux te filer les sources de cette dll mais je doute que ce soit une bonne idée.

Non t'en fais pas je vais me débrouiller. C'est juste que je trouvais ton code interessant car je n'arrive pas à saisir comment faire un select d'une table, afin d'entrer les valeurs des colonnes de ma table dans un objet métier.

Bref je n'arrive pas à faire de SELECT, c'est super 8O.

Voir 40 message(s) de cette discussion en une page