Passage de Java à C# : les Bibliothèques

Bonjour tous le monde!

En plein apprentissage (autodidacte) de la programmation orienté objet, j'ai quelques difficultés à faire le passage Java -> C#.

Des problèmes qui seront je pense simple à résoudre pour vous, mais qui me posent des difficultés, et je ne trouve pas de solutions sur le net, ou en tout cas, pas qui me parlent assez pour m'aider.

Avec Java (en utilisant Eclipse), la gestion des packages est assez simple, clique droit sur le projet, "add package", et ensuite on crée des classes à l'intérieur. On ajoute les imports également facilement puisque c'est le logiciel qui nous le propose. J'ai pu remarquer également que les packages étaient des dossiers organisés dans le projets.

Et avec Visual Studio, j'ai beaucoup de mal à comprendre comment tout ça fonctionne.
J'utilise le modèle MVC, donc mon but serait de faire un package pour chaque partie, et je n'arrive tout simplement pas à trouver quelque chose qui ressemble de près ou de loin à ce que j'ai pu trouver sur Java (certainement là où est le problème, la logique de Visual Studio ne doit pas être la même et m'échappe).

Donc je demande votre aide pour m'aiguiller, m'expliquer ou me faire passer un lien vers une page que j'aurai loupé.

Merci beaucoup :ccool:

Salut !

En C# avec VS, ça marche plutôt par Projets (typiquement pour tes controleurs) / Class Library (pour la couche de service et les UserControls).

La différence c'est que les class library ne peuvent pas être exécutée directement, alors que les projets, oui (clic droit sur le projet > set as StartUp Project).

Après dans le détail quelqu'un saura certainement mieux t'expliquer que moi, j'espère t'avoir mis un peu sur la voie :oops:

Bon courage !

Merci pour ton message!

Ta réponse m'a mis sur un chemin, je ne sais pas si c'est le bon, mais ça commence à me parler.

J'ai créer un projet ou seront placé mes classes du controleur.
Et ensuite j'ai fait "fichier->Add->New Project->Class Library" et ça m'a rajouté dans l'explorateur de solutions ce nouveau projet (qui sera pour moi l'équivalent de mon package vue ou modèle).

Ensuite, d'après ce que j'ai trouvé sur le net, je vais devoir créer mes classes dans cette library, et ensuite faire build pour créer le .dll et pouvoir l'ajouter aux références du projet puis faire l'import.

Je vais en tout cas essayer dans cette direction.

Quand tu utilises Visual Studio, il y a plusieurs choses à connaître.

Tout d'abord, le projet :

Un projet a un type d'output bien défini (dll, exe, etc..) et sert à découper ton projet. Pour reprendre ton exemple du MVC, pour bien découpler ton projet, tu dois avoir au minimum 3 projets : Un projet d'affichage (Peu importe que ce soit une IHM console, un client riche ou un client web), un projet dll qui contiendra ton modèle et un projet qui contiendra ton controlleur.

Rien n'empêche d'avoir plus que ces trois briques de base, c'est même souvent le cas. Par exemple, tu peux faire un projet qui contient tes POCOs (l'équivalant des POJOs de Java), un projet qui contient un Framework, etc...

Au sein de ces projets, tu peux créer des dépendances, c'est à dire de définir "qui connait qui". Par exemple, ton controller peut connaître tes POCOs et les utiliser mais tes POCOs n'ont en aucun cas à connaître ton controller. Dans ce cas, tu fais clique droit sur ton projet controlleur, tu ajoutes une référence vers tes POCOs et ton controller pourra les utiliser.

Ensuite, la solution :

Une solution est juste un espace où sont contenus tous les projets qui ont un lien. Par exemple, tu fais un framework de tests unitaires. Tu vas créer une solution et un ou plusieurs projets qui feront parti de son framework. Si ensuite, tu souhaites utiliser ce framework dans une autre application, tu n'ajoutes pas les projets à ta solution mais tu ajoutes une référence sur la/les dll qui ont été générée par cette solution précédente. De cette manière, tu peux utiliser les classes qui sont contenues dans la dll sans avoir des projets qui n'ont aucun lien avec ta solution actuelle. Tu utilises le même mécanisme si tu souhaites utiliser une dll que tu as téléchargé sur internet.

Enfin, les namespace :

Je crois que c'est ce qui s'approche le plus des packages en Java. Quand tu déclares une classe/interface/struct/etc, tu la déclares forcément dans un espace de nom (namespace). Ce sont les namespace qui permettent de déclarer deux classes du même nom à deux endroits différents. Sinon, comment faire pour utiliser la classe Message d'un framework si on a soit même déclarer une classe Message ? On peut donc différencier en créeant une instance soit de Framework.NamespaceDeOuf.Message ou MonSuperProjet.NamespacePourri.Message.

Pour éviter d'avoir à citer le namespace correspondant à chaque fois que l'on utilise une classe, on peut utiliser l'instruction using qui permet de spécifier tous les namespaces avec lesquels on souhaite travailler.

VS rajoute des super options afin de ne pas se prendre la tête en plus ! Par exemple, si tu sait que tu dois instancier une classe Message d'une librairie que tu as ajouté en référence mais que tu ne connais pas le namespace, pas besoin de googler pendant des heures : Un simple clique droit sur le nom + Resolve et tu peux l'ajouter automatiquement à tes usings ou choisir de l'afficher avant le nom de la classe. Mais que demande le peuple ? :D


J'espère avoir fait un tour d'horizon assez concis pour ne pas te perdre et assez complet pour que tu comprennes comment fonctionnent les solutions et les projets sous VS. Si tu as d'autres questions, n'hésite pas !

Merci pour ta réponse très complète!

Malheureusement... J'ai pas pigé grand chose :lol:

Plus sérieusement, j'ai vraiment un niveau de débutant et tous ces "options" de VS me perdre... J'en suis au niveau ou j'ai des bases théorique qui me permette de vouloir faire des choses, mais ou la pratique et le vocabulaire me bloque...

Je pense que le plus simple et que j'explique ce que je souhaite faire pour te donner une idée plus précise :

Je viens de créer un projet (empty project) "monProjet" ou j'ai crée une classe Controle. C'est là ou se trouve la partie controleur.
Dans cette cette classe, j'ai écris la procedure static Main() qui va instancier ma classe Controle, qui elle dans son constructeur, va instancier ma classe frmPrincipal en lui envoyant en paramètre ma class Controle (this).

J'ai ensuite ajouter une library class "vue", ou j'ai créer une classe Window Form "frmPrincipal".

Mon but est que l'application s'ouvre sur cette fenêtre. Après avoir crée ma class Library "vue", j'ai fait build pour créer mes .dll ce qui m'a permis d'ajouter "vue" aux références de "monProjet".

C'est un cheminement typique que j'avais déjà réalisé sous Java.
Et dans ma class frmPrincipal, dans le constructeur, je valorise une propriété de type Controle avec le paramètre reçu. Pour les faire communiquer entre eux.
Mais ma class Controle n'est pas reconnu, donc je me dis logiquement (dans ma logique hérité de java) que je dois juste faire un import.

Et mon soucis est que je ne peux pas ajouter en références "monProjet", VS me dit:

Citation:

---

A reference to "monProjet" could not be added. Adding this project as a reference would cause a circular dependency

---

Et si j'écris en haut de ma class "using monProjet" celui ci n'est pas reconnu.

Donc voilà ou j'en suis, je sais que les réponses sont certainement dans ton message, mais je n'arrive pas à les décoder, encore désolé!

Il n'y a pas de soucis, ce sont des choses qui viennent petit à petit.

Quelques réponses à ton précédent postes :

- Je ne suis pas un spécialiste du MVC (Je développe quasi-toujours en N-tier) mais je ne pense pas que ce soit à ta classe controller de posséder une méthode main. En général, celle ci est plutôt dans la vue.

Je vais essayer de t'expliquer un peu comment découper en couches :

On va partir de la base, c'est à dire notre modèle de données. C'est ici que l'on mettra tous nos objets qui ne servent qu'à contenir des données. Je crée donc une nouvelle solution et un nouveau projet de type dll. Dans celui ci, je crée toutes mes classes POCO, par exemple la classe Person qui a un age, un prénom et un nom, la classe Livre, qui contient une référence, un titre, un auteur, etc ...

Ensuite, je crée une couche (DAL, Data Access Layer, Couche d'Accès aux Données) qui va intéragir avec une base de données par exemple. J'ajoute à ma solution un projet de type class library dans laquelle je créerais des classes dont l'unique rôle sera de faire le lien entre les POCO et la DB. Pour que celle ci, puisse connaître et manipuler les POCOs, j'ajoute une référence sur le projet POCOs dans mon projet DAL.

Je te donne un exemple A NE SURTOUT PAS FAIRE pour te donner une idée :

Citation:

---

public class PersonDAL
{
public void SavePerson(Person p)
{
string request = "INSERT INTO PERSON VALUES('" p.FirstName "'"); // Etc ...
}
}

---

En gros, la classe permettra de créer des objets Person à partir des infos extraites de la DB et d'enregistrer des objets Person dans la DB.

Ensuite, on ajoute un autre projet qui va gérer la logique métier de l'application. C'est ici que l'on va faire toutes les manipulations nécessaire. Par exemple, si une personne loue un livre, c'est ici que l'on va faire une méthode Rent(Person p, Book b) qui contiendra tous les appels aux méthode exposées par la couche précédente. Je rajoute encore un projet de type dll que je peux appeller BLL (Business Logic Layer, Couche de Logique Métier) où j'ajouterai des références sur les POCOs et sur le projet DAL, afin de pouvoir utiliser les deux.

Enfin, on crée le projet de l'IHM, qui sera soit un projet console .exe, soit une appli WinForm/WPF .exe, soit une appli Web Silverlight/ASP, etc ... On ajoute une référence vers le projet BLL et le projet POCO afin de pouvoir faire correspondre au clic ou à la commande entrée un appel d'une méthode de la BLL.

Je t'ai ici expliqué les grandes lignes de création d'un projet en architecture 3-tier. Que ce soit N-tier ou MVC ou autre, un pattern d'architecture a un seul but : Le découplage. C'est à dire qu'on peut vouloir remplacer une partie ou changer le fonctionnement du logiciel, sans avoir à bidouiller partout. Je m'explique :

Imaginons que tu crées un projet console selon les quelques explications que je t'ai fournies. Tu stockes tes infos sous MySQL, tout va bien. Un jour tu te dis que ton projet pourrait être utile à plein de gens et que tu comptes en faire un site web: Tu passes donc sous SilverLight. Contrairement à un projet mal découpé, si tu fais cela, tu n'auras rien à changer dans ton code.

Tu ajouteras juste un projet de type Silverlight, auquel tu ajouteras une référence sur ta BLL et quand l'utilisateur cliquera sur un bouton, ça fera la même chose que quand tu rentrais des lignes de commande : Ca appellera la fonction Rent de la BLL par exemple.

Tu pourrais donc avoir un site web, une application riche et une appli en ligne de commande qui soient complètement différents physiquement mais qui fonctionne de la même manière car ils réalisent les appels à la même BLL qui n'a pas changée.

Pareillement, si tu estimes qu'une DB sert à rien et que c'est mieux de stocker tout ça dans un fichier XML, tu n'as qu'à créer une autre DAL qui fait l'échange entre le fichier XML et les POCOs et ta BLL n'y verra que du feu car elle ne fait qu'appeler un WebService ou une méthode à travers une interface.

Que la méthode Insert(Person p) insère une ligne en base ou l'écrive dans un fichier, ta BLL s'en fout. Elle appelle juste Insert() sur un objet à travers l'interface IDAL et elle ne sait pas si derrière c'est un objet de type XMLDAL ou DBDAL ou autre, elle appelle juste Insert().

C'est ce qu'on appelle le couplage faible. C'est quand tu peux changer une couche et en mettre une autre à la place, si tu as bien écrit ton programme, tu n'as rien à changer ailleurs.

Je te conseillerai de laisser tomber les histoires de faire du MVC pour le principe de faire du MVC et t'intéresser dans un premier temps à comprendre vraiment la POO, le polymorphisme, le couplage, etc ... Ensuite tu comprendras bien mieux comment fonctionnent les références et autres sous VS et tu pourras enfin te lancer sur le chemin des patterns architecturaux.

D'ailleurs pour l'avenir, quand tu essayes d'ajouter une référence à un projet et que tu as une dépendence circulaire, c'est la plupart du temps (tout le temps ?) que tu as un problème d'architecture.

Merci beaucoup pour ta réponse, je vais bien prendre le temps de la comprendre
et d'étudier tout ça, histoire de ne pas poster 30 posts pour rien.

Merci beaucoup:ccool:

Pour Maxime :

Je viens de passer la matinée à étudier ta réponse. Et ça a été riche en enseignement. Je me suis renseigné sur l'architecture n-tiers, j'ai essayé de bien analyser la solution que tu expliquais, et j'ai deux trois questions:

1) Quand tu dis créer un projet de type .dll, concrètement quel choix fais-tu dans VS? (c'est un peu débile mais bon j'ai pas réussis à trouver...).

2)Quand tu parles de couches :

Citation:

---

"Ensuite, je crée une couche (DAL, Data Access Layer, Couche d'Accès aux Données) qui va intéragir avec une base de données par exemple. J'ajoute à ma solution un projet de type class library dans laquelle je créerais des classes dont l'unique rôle sera de faire le lien entre les POCO et la DB. Pour que celle ci, puisse connaître et manipuler les POCOs, j'ajoute une référence sur le projet POCOs dans mon projet DAL."

---

Je ne sais pas si tu parles de façon concrète (dans le projet POCO tu ajoutes un item DataSet pour créer une Data Access Layer et ensuite tu crée un projet class Library) ou si tu parlais de couche en ajoutant un projet class Library et tu crées les classes qui vont faire le lien entre la DB et les POCOs et c'est ce projet qui est ta "Data Access Layer".

3)Je n'ai pas vraiment compris ton exemple "a ne pas faire"... le projet class Library doit contenir des classes qui font le lien entre la DB et les POCOs, donc elles contiendront du SQL, qu'a tu voulu me dire avec cet exemple?

4)Les classes de la première couche, du projet POCOs, vont être au final des classes qui vont contenir que de l'information? Aucune méthodes/interfaces?
Quel est vraiment le but?

Si je résume (ce que j'ai compris), nous avons le projet 'POCOs" ou des classes qui vont contenir des données vont être crée. Ces classes seront instancié par la couche DAL, qui va créer les objets du projet POCOs avec les informations récupérée de la DB. La couche DAL à en faite pour rôle de manipuler les informations de la base de données et de modifier les POCOs en conséquences.
Ensuite on a la couche BLL, qui elle va avoir des classes qui vont réaliser les actions du logiciel, selon l'action de l'utilisateur.
Si je reprend ton exemple de la méthode Rent(), cette méthode doit appartenir à une classe 'Livre', ou quelque chose comme ça. Donc on retrouvera les "thèmes" des classes du projet POCOs.
Donc logiquement je me dis que la partie "proprieté" des classes et dans le projet POCOs, et la partie interface dans le projet BLL.
Est-ce la bonne logique? Celle que tu as voulu m'expliquer?

Et pourquoi ne peut-on pas avoir comme première couche la couche DAL
avec au dessus la couche BLL qui possède des classes avec les proprietés qui seront géré par la couche DAL et l'interface qui remplira le même rôle que dans ton exemple?
Enfin est-ce possible, ou il y a vraiment un avantage à utiliser comme première couche un projet avec des classes qui vont contenir des données?

N'hésite pas à me dire si je suis à côté de la plaque aussi hein, pas de soucis!
Merci:ccool:

Tant mieux si j'ai pu t'apprendre des choses :)

Pour répondre à tes questions :

1) Projet de type bibliothèque de classe. DLL signifie Dynamic Link Library où Library est une faux ami qui ne veut pas dire librairie mais bien bibliothèque. Quand on parle d'utiliser des librairies on entend par là le terme anglais library mais c'est un peu un abus de langage (Enfin, on parle tellement en franglish dans le monde du dev que c'est pas super grave :p C'était un petit point culture :D)

Quand tu crées un projet et que tu en sélectionnes un, ça te donne des précisions sur la droite. Dans le cas d'un projet bibliothèque de classe ça te dit à droite que c'est la création d'une .dll.


2) Non, la DAL sera bien composée d'un ou plusieurs projets complètements indépendants des POCOs. Par exemple, j'aime beaucoup utiliser EF comme DAL pour DB car si je dois changer de SGBD, je n'ai rien à changer dans mon code, juste à regénérer mon edmx :)


3) Si je dis à ne pas faire, c'est pour plusieurs raisons. Tout d'abord, taper du SQL dans le code en brut c'est pas forcément conseillé. Si tu ne peux/veux pas utiliser d'ORM pour faire le lien entre ta DB et tes objets, tu peux taper du code SQL dans une classe, mais tu devras créer une DAL principale générique qui utilisera un objet qui contiendrait les différentes lignes de SQL relative à une DB en particulier.

Mais comme je te l'ai dit dans mon message précédent, une DAL ne veut pas forcément dire stockage des objets dans la DB, mais ça peut être dans un fichier, un flux, etc ..


4) Les classes POCOs ne sont pas vraiment une couche car elles sont exploitées dans tout le projet. Elles ont vraiment une vocation de structures de données transversales au projet.

Les POCOs sont ce que l'on en fait. Certains estiment qu'elles ne doivent en aucun cas contenir des méthodes, d'autres trouvent normal qu'elles en contiennent quelques unes relative à leur fonction. Bref, c'est à chacun de faire la part des choses et de choisir quoi mettre dedans.

Citation:

---

Ces classes seront instancié par la couche DAL, qui va créer les objets du projet POCOs avec les informations récupérée de la DB. La couche DAL à en faite pour rôle de manipuler les informations de la base de données et de modifier les POCOs en conséquences.

---

Oui et non. Comme je te l'ai dit, les POCOs sont vraiment transversal. Par exemple, si l'utilisateur remplit un formulaire avec son nom, son prénom et son age, tu peux faire de la manière suivante :

Tu récupères les valeurs du formulaire dans ta vue, tu appelles la méthode CreateNewUser(string firstname, string lastname, int age) de la BLL. Cette méthode se charge de créer un objet POCO à partir de ça, par exemple new User() { FirstName = firstname, LastName = lastname, Age = age};. Une fois l'objet crée, il va pouvoir être manipulé plus simplement que 2 strings et un int que l'on baladerait de constructeur en constructeur.

J'ai pas de super exemple, mais par exemple si tu souhaites faire une méthode IsLegal() pour savoir si la personne est majeure et que tu ne souhaites pas le faire dans ton POCO, tu peux très bien faire "public bool IsLegal(User user)" qui sera plus clair qu'un "public bool IsLegal(int age)". Une fois que ta BLL a crée l'objet, elle s'occupe d'appeler la méthode de la DAL chargée de faire persister l'objet : Par exemple, "Insert(User user)".

L'avantage que les POCOs soient séparés des couches c'est que la DAL peut manipuler ces objets sans connaître la BLL, alors que si ces entités faisaient partie de la BLL, la DAL serait obligé de la connaître.

Citation:

---

Si je reprend ton exemple de la méthode Rent(), cette méthode doit appartenir à une classe 'Livre', ou quelque chose comme ça.

---

En général, 'Livre' serait plus un nom de POCO, car on s'attend à retrouver uniquement des champs qui contiennent des information sur le Livre a l'intérieur. La méthode Rent() serait plutôt dans une classe BookManager qui se chargerait de gérer les livres comme son nom l'indique.

Cette classe, située dans la BLL, se chargerait de gérer tous ce qui a attrait aux livres, les emprunts, les disponibilités, etc ... Elle pourrait contenir la méthode Rent(User user, Book book), dans laquelle elle pourrait appeler la méthode IsAvailable(Book book) de la DAL afin de savoir si le livre n'est pas déjà emprunté, la méthode IsAllowedToRent(User user) afin de savoir si l'utilisateur a le droit d'emprunter ou s'il a trop de retard sur ses livres précédents pour pouvoir en emprunter un autre. Toutes ces méthodes sont du ressort de la DAL qui fait la requête SQL correspondante et retourne juste un booléen.

Une fois que toutes les vérifications ont été faite, il appelle la méthode DAL pour dire que c'est cette personne qui emprunte le livre et que ce soit enregistré en DB. Une fois cette insertion finit, il renvoie true pour dire que ce s'est bien passé.

Si on résume, l'utilisateur clique sur le bouton, la BLL utilise la DAL pour faire les vérifications nécessaires, l'insertion et retourne un booléen qui permettra d'afficher un message d'erreur ou de réussite. La vue appelle juste la méthode de la BLL correspondante et affiche un message selon le résultat. La BLL se base sur la DAL et c'est la seule qui connait les vérifications à faire dans le process de la location de livre. Et enfin, la DAL contient des méthodes basiques qui permettent de retourner si un livre est dispo ou si un utilisateur a du retard dans ses emprunts. Les couches d'abstractions sont donc respectées, chacun fait son rôle.


J'espère avoir pu répondre à toutes tes interrogations et je finirai sur la chose suivante :

Je t'ai présenté ici ma manière d'appréhender et de penser l'architecture de mes projets. Celle ci est loin d'être universelle et est avant tout ma manière de voir les choses. Libre à toi de la suivre ou d'en suivre un autre (Promis je ne me vexerai pas :aie:) et dans le temps tu apprendras à suivre tes propres best practices. Ce que je te conseille dans un premier temps, c'est de ne pas te formaliser sur un pattern en particulier (genre MVC, 3-tier, ou autre) et de piocher à droite et à gauche dans les différentes best practices afin d'arriver à un code qui respecte plusieurs principes de base essentiels.

Tout d'abord, le code doit être lisible, clair et commenté (ou pas) avec parcimonie. Peu importe comment tu l'écris, il doit être compréhensible par quelqu'un d'extérieur au projet du premier coup d'oeil. Ensuite, chaque classe doit avoir un et un seul rôle. C'est idiot qu'une classe serve à stocker des données, à les manipuler, à les enregistrer en base et à les afficher. A chaque classe un rôle défini et point barre. Et pour terminer, le couplage doit être le plus faible possible, c'est à dire qu'il faut que tu aies en tête qu'à tout moment, le comportement d'une classe peut changer sans que ça ait à affecter tout ton code.

Pour reprendre l'exemple du stockage, quand ta BLL appelle Insert(), si il l'appelle sur une classe StockageEnDB, le jour ou tu dois utiliser la classe StockageEnFichier, tu dois changer ton code métier, alors que tu as juste changé de méthode de persistance. Si tu faisais un appel sur un type IStockage, peut importe que le type sous jacent soit StockageEnDB ou StockageEnFichier ou StockageEnAtomes, ça stockera l'information, et c'est tout ce que qui intéresse la BLL.

J'espère que ce pavé t'apporteras plus de réponses que de noeuds à la tête :mouarf:

Non ne t'inquiète pas, ta réponse va beaucoup m'aider encore une fois.
Et les nœuds à la tête, le jeu c'est de les défaire pour comprendre, sinon ça serait trop facile et pas amusant de tout comprendre d'un coup.

En fait là je suis surtout à la recherche de compréhension afin de visualiser ce que je vais faire pour réaliser mon petit logiciel en C#. MVC, n-tiers, ou autre, peu importe, ce que je veux c'est coder et progresser (et ensuite après un peu de temps, je pourrai "préférer" une méthode ou une autre).
Et ce que j'ai appris sur Java a l'air d'être simpliste en terme d'architecture, donc normal que je doive me creuser un peu la tête pour passer au niveau "au dessus".

En tout cas merci pour ta patience, ce soir j'ai pas le temps de vraiment m'y mettre, mais je vais bien étudier ta réponse et d'après ce que j'ai vu, il y a l'air d'avoir beaucoup de réponses à mes questions ! :ccool: