Discussion :

[atoutsweb]

Bonjour et merci d'avance,

j'ai une petite question à propos de la conception générale d'une application ;

Lors du lancement d'une application, il est nécessaire d'initialiser des objets, des connexions à des bases etc.

Il est évident que ces opérations peuvent être réalisées dans le form1 mais je pense du coup qu'on ne respecte pas les n/tiers.

D'après votre expérience, faut t'il ainsi créer une sorte de classe init et doit t'on l'appeler depuis la classe programs ?

2ème question, je dois utiliser des objets communs sur plusieurs forms. Je m'oriente ainsi pour une classe "common" contenant des objets et méthodes statiques. Mon orientation vous semble t'elle bonne ?

Merci pour votre expérience.

[Thomas Lebrun]

Pour le 1, tu créés 3 projets dans ta solution:
- projet GUI: C'est l'interface utilisateur
- projet DAL: C'est la que tu va faire les connexion à la base de données par ex et crééer des méthodes du type GetEmployees, etc..
- projet BLL: C'est là que tu créés des méthodes qui vont appeller les méthodes de la DAL.

[PoZZyX]

hello,

je me permet de m'incruster parce que ma question est un petit peu apparentée.

Je suis assez débutant (d'ailleur si tu pourrais expliquer de façon un petit peu plus détaillée tes 3 projets dans une solution, ou un lien vers un tutorial ou qqchose ça serait cool).

Pour en revenir a mon problème, je fais une application ou j'aimerais que tout mes formulaires soit similaires (question apparence). Pour ce faire, j'ai créé un formulaire frm_template ou j'ajoute des images qui doivent etre présentes partout. Ensuite, sur tous les forms je mets : public partial class frm_test : frm_template comme déclaration de la classe. Est-ce la bonne méthode ???

De plus, dans ce frm_template, j'ai un label titre. Comment je fais pour que chaque formulaire (qui se base sur frm_template) aie un texte différent pour ce label ???

Merci d'avance pour ces réponses et dsl si je m'inscruste de façon malpolie, si ça dérange je créé un nouveau sujet.

[Thomas Lebrun]

Pour en revenir a mon problème, je fais une application ou j'aimerais que tout mes formulaires soit similaires (question apparence). Pour ce faire, j'ai créé un formulaire frm_template ou j'ajoute des images qui doivent etre présentes partout. Ensuite, sur tous les forms je mets : public partial class frm_test : frm_template comme déclaration de la classe. Est-ce la bonne méthode ???

De plus, dans ce frm_template, j'ai un label titre. Comment je fais pour que chaque formulaire (qui se base sur frm_template) aie un texte différent pour ce label ???

Passer par un template est une bonne idée

Il faut juste que tu créées ensuite des forms qui hérite de ce template

[Mose]

je fais une application ou j'aimerais que tout mes formulaires soit similaires (question apparence). Pour ce faire, j'ai créé un formulaire frm_template ou j'ajoute des images qui doivent etre présentes partout. Ensuite, sur tous les forms je mets : public partial class frm_test : frm_template comme déclaration de la classe. Est-ce la bonne méthode ???

Oui

De plus, dans ce frm_template, j'ai un label titre. Comment je fais pour que chaque formulaire (qui se base sur frm_template) aie un texte différent pour ce label ???

Dans ta form parente, tu créé une propriété abstraite "Title". Dans le constructeur, tu changes le titre de la form pour qu'il soit égal à Title.
dans chacune des classes filles, tu n'as plus qu'à définir la propriété title pour qu'elle renvoie le titre que tu souhaite.

[PoZZyX]

Ah ça marche, merci bien pour cette réponse !!!

Mais est-ce normal que j'aie un warning :
Avertissement 1 Le concepteur doit créer une instance de type 'projet.frm_template' mais il ne peut pas, car le type est déclaré comme abstract.

Je ne pense pas que ce soit normal. J'ai du déclarer mon template comme cela :
abstract public partial class frm_template : Form

Est-ce correct ?

[Mose]

Si tu fais une Form en abstract, tu ne peux plus l'utiliser dans le designer.
Je sais même pas si t'as le droit d'éditer une Form qui en hérite...

Conseil : fait d'abord ta Form tout comme il faut et à la fin, quand t'as plus besoin de designer, passe-la en abstract et gère ses filles.

Le designer de VS.Net est vraiment, mais vraiment tout pourri.
Il est pas du tout objet, ça me fait bien rire

[atoutsweb]

Pour le 1, tu créés 3 projets dans ta solution:
- projet GUI: C'est l'interface utilisateur
- projet DAL: C'est la que tu va faire les connexion à la base de données par ex et crééer des méthodes du type GetEmployees, etc..
- projet BLL: C'est là que tu créés des méthodes qui vont appeller les méthodes de la DAL.

Merci, j'avoue que je ne m'attendais à tant de changements pour mieux séparer les couches mais je comprends bien l'intérêt.

[atoutsweb]

Bonjour et bon premier mai !

Je tente de mettre en place l'architecture 3/3 mais il m'est assez difficile de trouver de la documentation.

Je pars sur ce principe donc de 3 projets :

{DATA LAYER}
{BUSINESS LAYER}
{UI_LAYER}

Au début de l'application je veux tenter une connexion au serveur DB, je procède ainsi :

1) Le classe {projetUI}.program crée une instance de la classe {projetBL}.acces_db et appele ainsi son constructeur.

2) Le constructeur de {projetBL}.acces_db crée une instance de la classe {DL}.BaseDeDonnees

3) Le constructeur de {projetDL}.BaseDeDonnées lance la connexion au serveur DB et retourne éventuellement un throw

Ainsi : {ProjetUI}.* ne peut pas accéder à {ProjetDL}.*

Suis-je dans la bonne direction ?

Dernière question, mes 3 projets doivent accéder à un même namespace, je dois donc mettre le namespace sur le premier projet généré (DataLayer) ?

Merci !

[Thomas Lebrun]

Cela semble pas mal même si je te dirais de passer par un singleton pour tes classes BLL et DAL (mais bon, c'est pas forcément obligatoire)

Dernière question, mes 3 projets doivent accéder à un même namespace, je dois donc mettre le namespace sur le premier projet généré (DataLayer) ?

Pkoi ? Rien ne t'oblige à ce qu'il soit dans le même namespace

[Mose]

Je tente de mettre en place l'architecture 3/3 mais il m'est assez difficile de trouver de la documentation.

Sujet abordé très régulièrement sur votre forum préféré
Un post précédent sur le 3-tiers.

2) Le constructeur de {projetBL}.acces_db crée une instance de la classe {DL}.BaseDeDonnees
...
Suis-je dans la bonne direction ?

Ah non, pas du tout.
L'idée dans le 3-tiers, c'est que chaque couche se fout éperduement de la façon dont est gérée la couche en dessous.
Or ici, ta couche métier gère le fait que tu travailles avec une base de données.
Ca n'est donc plus du 3-tiers.

La réflexion de base dans le 3-tiers, c'est de se dire qu'on doit pouvoir modifier une couche sans avoir à toucher une ligne des couches supérieures.
Exemple :
* Je bosse aujourd'hui avec une BDD Sql Server. Demain je veux pouvoir bosser avec une BDD MySql.
* Je bosse aujourd'hui avec une BDD Sql Server. Demain je veux pouvoir bosser avec un fichier XML.
* Je bosse aujourd'hui avec une BDD Sql Server. Demain je veux pouvoir bosser avec les meta-data-provider-turbo de .Net 7.1

De la même façon avec la couche interface :
* Aujourd'hui je fais une appli WinForm. Demain je veux faire la même sous Mono.
* Aujourd'hui je fais une appli WinForm. Demain je veux faire la même appli en ASP.Net.
* Aujourd'hui j'ai pas le temps de faire mon appli WinForm, du coup dans la v0.9 je fais une appli console.

Le but, tu l'auras compris, c'est de permettre l'évolutivité.

Perso, ma couche donnée n'expose que des DataSet fortement typés (conteneur de données brutes), et des méthodes du genre GetUserByID(int id).
Après tout ce qui concerne la connexion est géré automatiquement. La couche métier ne sais pas qu'il y a une base de données derrières.

[Thomas Lebrun]

Le pb Mose, c'est que tu oublies qu'il est débutant dans la matière donc je suis à 95% sur qu'il ne voit pas ce que tu veux dire lorsque tu dis:

Après tout ce qui concerne la connexion est géré automatiquement.

@atoutsweb: Voila un peu comment tu pourrais organiser tout ca:


DAL: Tu fais une méthode GetEmployees() qui va se charger de se connecter à la base de données, et de faire une requête du type SELECT * FROM Employees. Ce n'est qu'une ébauche car comme je te l'ai dit, un Singleton serait bien:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
namespace DAL
{
     public static class EmployeesDAO
     {
           public static List<Employees> GetEmployees()
           {
                  // Ici, tu fais la connexion à la BDD, tu fais une boucle et tu remplit une List<Employees> qui sera renvoyé
           }
      }
}

L'avantage, c'est que si un jour on te demande de ne plus passer par une base de données mais par un WebService, tu créés une classe identique à EmployeesDAO, avec les même méthodes et tu changes juste le contenu (dans le principe c'est ca mais dans la pratique, c'est un peu.... porc de faire comme ca mais c'est juste pour que tu comprennes )



BLL: C'est tout simple: elle se contente d'appeller les méthodes de la DAL

Code :

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

1
2
3
4
5
6
7
8
9
10
 
namespace BLL
{
     public static class EmployeesManager
     {
           public static List<Employees> GetEmployees()
           {
                  return DAL.EmployeesDAO.GetEmployees();
           }
      }

UI: Elle se contente d'appeller les méthodes de la BLL. Par exemple, tu le click d'un bouton, tu fais:

Code :

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

1
2
 
myGridView.DataSource = BLL.EmployeesManager.GetEmployees();

Attention, la gestion des exceptions est absente et j'ai utilisé des classes/méthodes statiques ce qui n'est pas forcément le mieux (des Singleton aurait été ideal).


C'est plus clair comme cela ?