Discussion :

[miltone]

Salut à tous,

Je suis dans le développement de mon 1e outils sous .NET en me servant d'un GUI en winForms. Jusque là tout va bien mais je cherche à faire un développement en couche comme conseillé dans ce tutorial :
ftp://ftp-developpez.com/morpheus/ar...chitecture.pdf

Et je ne comprends pas bien tout les chemins qui vont être empruntés dès lors que je clique sur un bouton de mon UI qui va appeler une fonction et me retourné un résultat.

Mon domaine est le suivant :
4 couches (GUI / DAL / BLL / Objet Métier).
J'ai une classe d'objet métier avec laquelle je souhaite travailler.

Par rapport à mon domaine, si je souhaite avoir dans mon UI la liste de tous mes clients répertorié en base de données, quel serait toutes les interactions employées entre classe pour fournir ce résultat de manière assez précise ?

Auriez-vous de l'éclairage à me fournir d'un point de vue plutôt graphique, général que tout de suite du code.


Merci à vous,

[topolino]

ton UI doit appeler ta couche metier (BLL), qui elle apellera la couche de bdd (DAL). et le transport de tes donnees se feront via les objets metiers.
Pour les messages d erreur tu peux les recuperer avec un parametre out.

[miltone]

C'est justement le transport de mes données via les objets métier que je ne comprends pas bien. Comment cela se produit ?

As tu des explications ? références, articles ou tuto qui puisse m'aider à ce sujet ?

[ostenhard]

Bonjour,

Généralement, dans ton cas, on dit qu'on utilise un modèle 3 couches. Les objets métier sont dans la couche transverse. Donc un modèle 3 couches, c'est un modèle 3 + 1 couches.

La couche transverse est comme son nom l'indique transverse à toute ta solution.

Comment les objets métier transitent dans ton application ? Ben simplement par des paramètres ou/et des valeurs de retour.

En espérant que cette explication rapide t'aide un peu.

Bon courage

[miltone]

Merci pour vos réponses.
Je trouve cela vraiment dommage qu'il y est si peu de documentation et de partage de connaissance sur le web concernant ce sujet. Alors je compte sur vous pour justement comblé un peu ce vide en m'aidant. Mais si vous avez des références de livre ou des bons articles concernant le développement en couche je suis preneur.

Pourriez-vous me donner un avis sur ces questions svp ?

- Dois-je créer une classe DAO(Data Access Layer) pour chaque DO(Data Object) dans ma solution ?
- Quel sont les avantages à pouvoir déclarer un attribut du type de la classe elle-même ?
- Je n'ai pas bien cerné avec qui dialoguait les classes DO (Data Object)

[topolino]

Pour les docs, tutoriaux et exemples, regarde du cote des architectures MVC ou MVP avec ton moteur de recherche preferé, ou tout simplement sur le site developpez.

[ostenhard]

Dois-je créer une classe DAO(Data Access Layer) pour chaque DO(Data Object) dans ma solution ?

Moi j'en fais une par table en général. Attention une table ne veut pas dire un DO.

Quel sont les avantages à pouvoir déclarer un attribut du type de la classe elle-même ?

Peux-tu ré-exprimer ta question ?

Je n'ai pas bien cerné avec qui dialoguait les classes DO

Je dirais tout le monde qui en a besoin.

Prenons un exemple, disons les pays :

• Tu vas définir une classe Pays qui sera ton DO Pays
• Tu vas définir une classe PaysDAO contenant toutes les méthodes permettant de récupérer, modifier, créer des pays
• Tu vas définir une PaysBLL contenant toute la logique métier applicable au pays

Maintenant si dans ton UI tu as un bouton "charger tous les pays", là tu appelles la méthode GetAllCountries() de la classe PaysBLL. Cette méthode retourne une liste de pays.

Dans cette méthode, tu vas appeller la méthode GetAllCountries de la classe PaysDAO. Cette méthode retourne une liste de pays.

Là au démarrage d'un projet, à des fins de tests, généralement, on crée et retourne une liste bidon et avec l'avancement du projet, on va récupérer les pays à partir d'une BDD par exemple.

Dans la méthode GetAllCountries de PaysDAO, tu crées donc ta liste de pays en instanciant x fois ta classe Pays (DO).

J'espère avoir été clair !

[miltone]

Salut à vous,

Je ne vous est clairement pas oublié ne vous inquiété pas. J'ai été revoir l'architecture MVC et architecture 3Tiers comme conseiller.
Cela ne répond toujours pas à mes questions mais me donne une vision de plus en plus précise du contexte de mon problème.

Je vais surtout me lancer dans l'implémentation d'un code précis et travail à partir de celui-ci dans un second temps en l'amiliorant si besoin est.

Quel sont les avantages à pouvoir déclarer un attribut du type de la classe elle-même ?
Peux-tu ré-exprimer ta question ?

En fait je pense que cela est uniquement utile pour le design pattern singleton. Car cela permet de tester l'existence ou non d'une instance de la classe et si c'est le cas de renvoyer les informations utiles à sont utilisation.

Donc pour faire du Singleton nous avons besoin de passé en attribut de la classe, un attribut dont le type et celui de la classe.

On peut constater cette technique dans le tutorial que j'ai mentionné au début dans la classe ClientsDAO et ClientManager.




Je ne clos pas encore le début car je pense avoir des futurs questions après avoir essayé une implémentation de code multi-couche.