Discussion :

[touftouf57]

Bonjour,

Je sens la question un peu bete, mais bon!!

C'est juste pour vérifier que le concept est bien acquis.
Dans une DAL on ne met que les acces à la base de données:
Insertion, suppression, mise à jour, selection (le CRUD en fait).
Ainsi que les selections "filtrées" type getProduitsByCategorie(int idCat).

Et dans la BLL on effectue les traitements qui appellent ces acces?
type:

Code :

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

1
2
3
if(categorie!=null)
List<Produit> produits=DAL.ProduitDAO.getProduitsByCategories(Produits.idCat);
....

Mais j'ai trouvé sur la toile, des choses du type FillDataGrid(DataGrid grid, List<Produits> Produits) et ceci est placé dans la DAL.
Est-il malin de faire ceci dans la DAL?

[Mehdi_ab]

Bonjour,

Comme ça je dirai non, c'est pas du tout malin, pourquoi , et bein parcque c'est un mélange du choux et de carottes dans le sens ou, visiblement, la fonction remplis un datagridview a partir d'une liste des produits, et donc ça c'est pas une responsabilité de la DAL, parcque comme t'as dis , la DAL c'est CRUD et pas remplir mes composants IHM, parcque si par exemple je veux réutiliser ma DAL mais dans un programme console (pk pas ) , j'aurai la fonction FillDatagrid ki va servir a rien, si ce n'est avoir un fort couplage avec l'assembly system.Forms, et mme pour aller plus loin, je dirai que mme dans la couche IHM, il faut utiliser des patterns style MVP (model view presenter) , ou j'aurai une interface IView par exemple avec une fonction void FillProducts(List<Produits> produits), qui sera implémenté par la vue, et comme ça si demain j change en application web, ou n'importe, je n'ai qu'lmplémenté cette interface.

J'espére que j'ai répondu a votre question

[Philippe Vialatte]

Salut,

C'est juste pour vérifier que le concept est bien acquis.
Dans une DAL on ne met que les acces à la base de données:
Insertion, suppression, mise à jour, selection (le CRUD en fait).
Ainsi que les selections "filtrées" type getProduitsByCategorie(int idCat).

Yes, c'est plus ou moins ca.

Tu peux aussi avoir une implementation legerement differente, ou ta DAL ne gere vraiment que le strict minimum du CRUD, et ou ta couche metier/business/service passe des expressions ou des query objects pour faire le filtrage (c'est moins "pur" comme approche, mais dans certains cas, on ne peut pas y couper, surtout pour des modeles un rien touffus)

Mais j'ai trouvé sur la toile, des choses du type FillDataGrid(DataGrid grid, List<Produits> Produits) et ceci est placé dans la DAL.

Comme ça je dirai non, c'est pas du tout malin

+1

sans amener le debat sur les patterns de presentation, tu deportes de la logique de presentation sur une couche qui ne doit normalement s'occuper que de l'interface avec la base de donnees ou des DTO ->mal

[touftouf57]

Merci pour vos réponses. C'est très sympa.

Mais voila que maintenant je me pose une autre question.
La form référence la couche buisness.
Mais est-ce que la couche buisness référence la form? Dans ce cas la BLL deviendrait un controleur? exact?

[The_badger_man]

La form référence la couche buisness.
Mais est-ce que la couche buisness référence la form? Dans ce cas la BLL deviendrait un controleur? exact?

Un composant de bas niveau ne doit pas dépendre d'un composant de haut niveau.

La couche business ne référence pas l'interface graphique. Comme pour la DAL, elle doit pouvoir être réutilisable dans l'appli console de Mehdi_ab (par exemple ).

Le controleur se placera entre la form et la couche business.

[touftouf57]

Ok, mais je ne vois pas quoi mettre dans ma couche buisness alors.

Lorsque je clic sur un bouton de l'ihm je dois ouvrir une fenetre fille
Cette fenetre fille possedera un Datagrid ayant une datasource provenant de la base.

Donc dans la Couche DAO j'aurais:

Code :

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

1
2
3
4
5
6
 
       public DataSet getDocAttenteLivraisonAll() {
                SqlCommand cmd = new SqlCommand("SPB_GetItemAttenteLivraisonStatutReceptionNull");
                FillDSet fdSet = new FillDSet(new SqlConnection(this.ChaineCon),cmd);
                return fdSet.getDataSet();
        }

la classe FillDSet me permet d'éviter d'écrire tout le code SqlDataAdapter.fill......

Et du coté de mon controleur j'aurais:

Code :

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

1
2
3
4
5
6
 
      FrmDetailArticleCommande frmDetail = new FrmDetailArticleCommande();
                frmDetail.remplirUltraGrid(DAO.getDocAttenteLivraisonAll());
                frmDetail.MdiParent = this._frmReception;
                frmDetail.Show();
......

Vu qe je n'ai pas de calcul à faire la dessus, je ne vois pas quoi mettre dans ma couche BLL.
Les choses que je devrais faire seront de modifier le statut des documents une fois imprimé, par exemple.

Est ce c'est cela que je dois mettre dans la BLL?

Code :

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

1
2
3
4
5
6
7
8
9
 public void imprimeSelection(Dictionnary<String, Document> DicDocSelected) {
            //instanciation d'un nouveau Bon
            Bon rapport = new Bon(DicDocSelected);
            PrintDialog printDialog = new PrintDialog();
            //Affichage de la boite de dialogue d'impression, si résultat = ok fait
            if (printDialog.ShowDialog() == DialogResult.OK) {
                //imprime le rapport
                rapport.imprime(printDialog.PrinterSettings, true);
              }

J'ai bien un exemple mais justement il manque un petit exemple de code métier.

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
namespace DeveloppementNTiers.BLL
{
    public class ClientManager
    {
        private static ClientManager s_Instance;
        private static object s_InstanceLocker = new object();
 
        // Singleton
        public static ClientManager Instance
        {
            get
            {
                lock (s_InstanceLocker)
                {
                    if (s_Instance == null)
                    {
                        s_Instance = new ClientManager();
                    }
 
                    return s_Instance;
                }
            }
        }
 
        public ConnectionStringSettings ConnectionString
        {
            set
            {
                SqlFactory.Instance.CnxStringSettings = value;
            }
        }
 
        public List<Client> GetClients()
        {
            try
            {
                // Ici, on peut appliquer des règles métier
                return ClientDAO.Instance.GetClients();
            }
            catch (Exception e)
            {
                throw new CustomException("An error has occured", e);
            }
        }
    }
}

Une petite précision des règles métiers aurait été sympa, bien que le cours soit très intéressant.

Ou bien est dans la BLL que l'on traite les transactions??

Merci d'avance, j'ai l'impression d'etre encore et toujours dans une belle nébuleuse.

[bacelar]

Faire une application qui ne sert que d'interface client à une base de données n'est pas le meilleur exemple pour une architecture en couche.
Si c'est votre problème, autant utiliser les clients du gestionnaire de base de données, cela sera aussi illisible et abscond pour les utilisateurs non techniques.

Votre application doit avoir une valeur ajoutée par rapport aux données qu'elle manipule.
La DAL est là pour récupérer dans l'espace d'exécution les données de la base et les convertir en données simple car un bon DBA doit souvent dénormaliser la base pour avoir des performances optimales. D'où l'intérêt d'encapsuler ces données dans une couche; la DAL.

Une fois les données récupérées dans un formalisme simple, les règles métiers doivent s'effectuer dans la BLL. Un exemple de règle métier, c'est interdire un transfert de somme de plus de 10000€ si l'utilisateur n'est pas un manager ou initié un processus d'enregistrement de la transaction comme une entrée pour un processus de détection de financement du terrorisme ou d'évasion fiscale etc...
La couche de présentation ne devrait faire que de la mise en forme des données consolidées par les règles métiers.

.NET est extrêmement permissif sur l'architecture employée. Votre exemple est un cas pathologique d'application ou l'architecture en couche ne sert à rien : le client à une base de données. Mais essaye de vendre votre application à un trader qui veut une projection à 30 jours de ces investissements ou un calcul d'analyse de risque selon plusieurs modèles. Cela sera un grand moment de solitude, ou de rigolade.

[touftouf57]

Merci de cette réponse nocturne, mais j'ai pas bien saisi la dernière phrase

.NET est extrêmement permissif sur l'architecture employée. Votre exemple est un cas pathologique d'application ou l'architecture en couche ne sert à rien : le client à une base de données. Mais essaye de vendre votre application à un trader qui veut une projection à 30 jours de ces investissements ou un calcul d'analyse de risque selon plusieurs modèles. Cela sera un grand moment de solitude, ou de rigolade.

Je pense que je n'ai pas donné le bon exemple de chose à faire durant l'appli.
En fait je dois faire une application de réception de livraison.
L'appli se décompose en 3(4) parties:
-Le serveur qui écoutera les terminaux mobiles (scanner code barre)
-L'application mobile (des terminaux)
-L'interface d'administration des réceptions
-(la base de données)

Et donc après mettre cassé la tête, j'ai trouvé qu'il y aurait une partie métier concernant le traitement des réceptions (conforme à la commande, objets manquants, objet en plus)
Mais cette partie sera plutôt traité par le serveur (qui fera ses traitements), me trompe-je?

[bacelar]

L'architecture en couche ne tient pas compte de l'endroit ou chaque couche s'exécute.
La Bll peut aussi bien s'exécuter entièrement sur le serveur qu'à cheval entre le client et le server.
C'est fonction des technologies employées pour implémenter ces couches.

Il semble que vous avez trouvé une utilité à la couche business, c'est bien.
Mais votre dernière question, je ne la comprends pas très bien.