Discussion :

[Chycken]

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

[Isythiel]

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

Bon courage !

[Chycken]

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.

[MaximePalmisano]

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 ?


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 !

[Chycken]

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

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

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:

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é!

[MaximePalmisano]

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 :

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.