Compréhension MVC avec C#

J'essaye d'apprendre à utiliser le Pattern MVC pour une appli web mais j'ai du mal à bien comprendre comment l'utiliser, même après avoir vu un tas de tutos et de schémas. Voilà ce que j'ai compris :

• Séparation de la présentation de l'application - et des données qu'elle manipule, que ce soit sur une base de données et des fichiers ou un "modèle métier"

C'est là que je comprend la théorie, enfin je crois, mais pour la pratique... Comment séparer les contrôles utilisateur (interface graphique) de leur traitement ? Il y a bien un moment ou, par exemple on doit récupérer une donnée d'un TextBox, l'utiliser, et renvoyer un résultat dans un autre contrôle.

Sur ce que j'ai lu, il est dit que l'on peut avoir plusieurs vues pour un même modèle. Cela signifie qu'on présente exactement les mêmes données dans un rendu graphique différent ? Par exemple dans un tableau ou dans une liste déroulante ? C'est qu'une question de rendu alors, comme changer la déco mais pas le contenu.

J'ai besoin de savoir comment ça s'articule et ce que ça pourrait donner sur le langage que je maitrise le mieux.

Salut,

MVC n'a rien à voir avec C# vu que c'est un concept. Il faudrait peut-être d'ailleurs déplacer la discussion dans le forum conception.
J'appréhende assez mal MVC aussi. A mon avis ce qu'il faut retenir c'est les flux d'informations dans le modèle. Je viens de regarder sur Wikipedia:aie:
http://upload.wikimedia.org/wikipedi...lerDiagram.png
Qu'est-ce exactement que ce contôleur? On visualise à peu près la vue et le modèle, mais le contrôleur?

Citation:

---

Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser

---

Une couche métier (BLL) améliorée? Apparement puisque ce serait dans le modèle. Le modèle serait en même temps la BLL et la couche d'accès aux données (DAL)?

Citation:

---

Le modèle représente le comportement de l'application : traitements des données, interactions avec la base de données, etc.

---

MVC serait-il du 3-Tiers "laxiste"?
La vue, l'IHM, peut s'adresser directement au modèle pour récupérer des données. Ceci n'est pas possible dans le cas d'une architecture 3-Tiers.

Citation:

---

Il y a bien un moment ou, par exemple on doit récupérer une donnée d'un TextBox, l'utiliser, et renvoyer un résultat dans un autre contrôle.

---

Tout à fait et à mon avis cela n'a pas de rapport. La donnée de la textbox passera par le contrôleur qui se chargera si nécessaire de l'envoyer au modèle pour une mise à jour de la base.

MVC vs 3-Tiers? Y a-t-il un meilleur modèle? Je dirai mieu vaut un 3-Tiers maîtrisé qu'un mauvais MVC.

A+

Sinon je te conseil le pattern MVP :
http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

J'ai mis volontairement ce post ici comme c'est une question de préférence de langage sur un Design Pattern. Ce post aurait pu être mis dans conception mais j'avais besoin d'avoir des infos dessus sur un autre langage que Java ou PHP.

Je vais jeter un oeil au MVP.

Sinon, c'est hors sujet mais j'ai besoin d'un projet pour améliorer mes aptitudes niveau prog. associés à des Design Patterns, SQL n'est pas une priorité absolue mais peut faire faire partie de l'équation. Une idée pour ne pas perdre la main ? Ça fait 6 mois que j'ai eu le BTS et plus de taf dans l'informatique depuis, plus de temps je passe à ne pas en faire, plus il va être difficile de justifier ce vide. Une idée ?

Citation:

---

Envoyé par Aizen64

Ça fait 6 mois que j'ai eu le BTS et plus de taf dans l'informatique depuis, plus de temps je passe à ne pas en faire, plus il va être difficile de justifier ce vide. Une idée ?

---

Monter sur Paris?
Si BTS => t'es jeune. Monte à Paris galère un peu (beaucoup même) et monte en compétence. Il me semble qu'en informatique le boulot manque pas.

A+

Trouver un boulot avec le BTS ? Mouais, sans expérience c'est tendu actuellement, même sur Paris, j'ai passé pas mal d'entretiens ces derniers temps, ça se passe toujours bien en théorie, après pour une vraie embauche, c'est autre chose. Ce diplome à très peu de valeur, la preuve à cette heure ci je fais un boulot que je faisait quand j'avais 16 ans et que j'avais aucun diplome.

Tu as cherché dans quelle SSII? Tu as déposé ton CV sur lesjeudis?

Non, pas sur lesjeudis. Des SSII j'en ai vu quelques unes et elles étaient pas particulièrement motivées à embaucher quelqu'un sans expérience avec un BTS, et je te parle même pas de ses joueurs de flute dans les cabinets de recrutement. C'est pas sans raison que j'ai aussi cherché un travail n'ayant rien à voir avec l'informatique.

Bon allez... je vais me consacrer à autre chose que le PC, j'ai déjà passé trop de temps devant ce foutu écran.

Heu... sinon j'ai partiellement regardé le code du tuto de Microsoft, c'est quoi l'intérêt de mettre des interfaces partout ?

Ben essayes les offres d'emploi développeur http://emploi.developpez.com. Soigne ton CV avant de le mettre en ligne.
Y'a aussi dans une moindre mesure Viadéo.

Se trouver un projet c dur, faut tenir. T'as pas une belle mère qui veut un site sur la sophrologie toi? :mrgreen: Ou bien ton club de sport, ou de philatélie? Réponds à un appel d'offre du forum emploi de DVPZ

J'ai trouvé du taf en Provence grâce à qqn du forum.

Ouvre ton blog sur developpez et deviens une référence :)

Bon courage.

A+

Bonjour,

Tu pourrais t'inspirer de ce tuto qui decrit l'impelmentation du patron MVC

http://msdn.microsoft.com/fr-fr/libr...40(en-us).aspx


Bonne lecture

Le MVP me parait pas mal. Mais j'ai besoin d'indications, je comprends pas trop certaines choses au niveau du code : Lien pour télécharger l'ensemble du code source

C'est quoi le MVP.DTO ? Par exemple dans SimpleLookupDTO, ça sert à quoi les expressions "get" ? C'est un attribut en lecture seule ?
Pareil dans l'interface IViewCustomerView :

string Fax{set;}

Le "set" sert à quoi ?

J'ai du mal à comprendre l'ensemble, même si le code n'a pas l'air bien compliqué, je fais aussi abstraction du truc avec la base de données.

Y a quoi de si interessant à utiliser des interfaces partout ? Après tout, ça reste seulement un "corps" de classe avec seulement des signatures d'attributs et de méthodes. Elles doivent forcément être réécrites comme pour l'héritage. Ca me fait penser au Pattern "Strategy" ou on peut appliquer à volonté des traitements possibles à une classe sans les contraintes que générerai l'héritage. Si quelqu'un veut bien m'expliquer tout ça, de l'aide serait la bienvenue.

Citation:

---

Envoyé par Aizen64

Y a quoi de si interessant à utiliser des interfaces partout ?

---

L'utilisation d'interface est extrêmement pratique.
Ex 1: en ce qui concerne l'accès aux données, il existe la "DbProviderFactory". Il s'agit d'une classe qui génère les objets nécessaires à l'accès aux données uniquement par des interfaces. L'utilisation d'un tel code permet de changer de base de données sans revoir aucune ligne de code. Au contraire, si tu accèdes à ta base de données en utilisant uniquement des objets SQL, tu auras toutes les peines du monde le jour où tu souhaitera passer sous MySQL ou Oracle.
Ex 2: Je travaille sur un projet de passerelle permettant à ma boite de récupérer des informations à propos de quantité de produits disponibles ainsi que de leurs tarifs.
J'ai fait en sorte que mes classe implémentent toutes la même interface. Ainsi, je peux ne coder qu'une seule page web pour gérer les produits de tous mes fournisseurs. Il suffit que je passe le nom de mon fournisseur à ma fabrique pour récupérer les types associés.

Citation:

---

Envoyé par g_tarik0010

Tu pourrais t'inspirer de ce tuto qui decrit l'impelmentation du patron MVC

---

Euh, y'a un débat ouvert à propos des différences entre MVC et 3-Tiers, parce que là... Je vois plus trop de différences hormis les méthodes de communications entre les couches...

A+

Par manque de temps, pour l'instant je ne peux m'etendre sur le pattern MVP, mais je te donne un lien bien fait sur developpez.com : http://jab.developpez.com/tutoriels/dotnet/mvppattern/

Il explique de facon clair ce pattern.

En gros tu as une Interface qui relate tous tes cas d'utilisations, qui elle sera partagée par ta page aspx et inplementé par ton controller (presenter).

Ce n'est plus la page aspx qui va chercher les données mais c'est le presenter qui lui push les informations. L'avantage c'est que l'interface graphique (UI) reste independante du developpement.

Que ce soit du winform, webform..... tu n'auras que la couche presentation a changer .

Citation:

---

Que ce soit du winform, webform..... tu n'auras que la couche presentation a changer .

---

Ca se fait très bien en 3-Tiers. Qu'ajoute le controleur?

Il pilote l'interface graphique.

C'est pour cela que l'ui peut etre facilement changé. Il fait la relation entre ce que veux l'ui et ce que lui transmets la BLL

Citation:

---

Envoyé par topolino

Il pilote l'interface graphique.

---

Ca veut dire quoi? Franchement j'ai du mal a visualiser. Merci de tes eclaircissements.

A+

l'interface graphique se contente d'émettre des événements lorsqu'une action est démandée.
Elle implement l'interface.

C'est à la charge du controller de communiquer avec les autres couches afin de recuperer les données. Et c'est lui qui les transmets et les valides avant de les donner à l'interface graphique.

Pourtant, en MVC on ne parle pas de couche.

Je ne comprends pas ta reponse.

C'est de l'ironie ?

Citation:

---

C'est de l'ironie ?

---

Bah non, loin de moi. Je veux dire que je n'arrive pas à definir la/les différences entre 3-Tiers et MVC. Mise à part le fait que l'UI peut s'adresser au modèle en court circuitant le controleur. Ou alors, je fais du MVC dans mon archi 3-Tiers....

Dans ton archi MVC tu as bien une couche DAL (data access layer), BLL (Business logic layer) et Intergace graphique.

J'ai pas d'archi MVC mais 3-Tiers classique BO, UI, BLL, DAL.
Y'a pas de traitement particulier (le moins possible) dans mon UI. C'est le role de la BLL. Ainsi je peux aussi bien faire une appli console que web. Donc franchement je vois pas l'intérêt du MVC. Je trouve mm cela plutôt risqué (court circuit du controleur, mais le controleur n'est pas la BLL). C'est pour cela que j'aimerai mieux comprendre de quoi il s'agit.

A+

Citation:

---

L'utilisation d'un tel code (interfaces) permet de changer de base de données sans revoir aucune ligne de code.

---

Comment ça, sans revoir aucune ligne de code ? Par définition, une interface ne fait rien du tout, les méthodes qui y sont associées doivent être réécrites pour une utilisation spécifique.

Citation:

---

l'interface graphique se contente d'émettre des événements lorsqu'une action est démandée.
Elle implement l'interface.

---

Dans tous les cas, peut importe le as d'utilisation, la couche de présentation de données, la vue (interface graphique) doit contenir le code qui transmet les données contenues dans des contrôles aux différentes couches de l'application, que ce soit à la couche métier pour des traitements ou à une base de données.

Je comprends le principe quand même, disons que dès qu'on voit un certains traitements ayant un certain rapport entre eux, utiliser une interface permet à d'autres classes d'implémenter quasiment n'importe quel comportement sans aucune contrainte.

Dans un site web, qu'est ce que tu veux dire par un évènement ? C'est pas tout à fait la même chose qu'une application "classique", un évènement est souvent déclenché par un clic sur un bouton, le bouton renvoie vers une page qui exécute un script pour récupérer, valider et renvoyer un résultat. Là je prends un exemple pour un site PHP, pour .NET les "évènements" web doivent plus ou moins être similaires.

Citation:

---

Comment ça, sans revoir aucune ligne de code ? Par définition, une interface ne fait rien du tout, les méthodes qui y sont associées doivent être réécrites pour une utilisation spécifique.

---

Oui, une interface n'a pas de code. Elle se contente d'enoncer des propriété, des méthodes.

Par contre, en instanciant un objet au travers de son interface me permet de manipuler l'objet toujours de la même façon. Dans le cas d'un accès aux données, l'ouverture d'une connexion se fait toujours de la même façon quelque soit le fournisseur de données. Dans le code ci-dessous tu peux remarquer qu'à aucun moment je ne manipule explicitement un objet SQL. C'est la méthode "DbProviderFactories.GetFactory" qui va me fournir mon objet en fonction du provider spécifié dans la chaine de connexion. Ainsi, ce code fonctionnera toujours, quelque soit la base de données que j'utiliserai.

Code:

---

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

public static void Select() { // Creation de la fabrique DbProviderFactory factory = DbProviderFactories.GetFactory(ConfigurationManager.ConnectionStrings["ChaineDeConnexion"].ProviderName); // Objet connection using (IDbConnection connection = factory.CreateConnection()) { connection.ConnectionString = ConfigurationManager.ConnectionStrings["ChaineDeConnexion"].ToString(); connection.Open(); // Objet Command using (IDbCommand command = factory.CreateCommand()) { command.CommandText = "SELECT * FROM usr_contract"; // Object datareader using (IDataReader reader = command.ExecuteReader()) { while (reader.Read()) { for (int i = 0; i < reader.FieldCount; i++) { if (reader[i] != DBNull.Value) Console.Write(reader[i].ToString()); else Console.Write("NULL"); if (i < reader.FieldCount) Console.Write("|"); } Console.WriteLine(); } } } } }

---

Citation:

---

utiliser une interface permet à d'autres classes d'implémenter quasiment n'importe quel comportement sans aucune contrainte.

---

Tu peux préciser?

A+

Je veux dire par là, qu'il est possible d'étendre les actions d'une classe indéfiniment. C'est difficile à expliquer, disons que le fonctionnement fait penser à un plug-in.

Citation:

---

Envoyé par Aizen64

Je veux dire par là, qu'il est possible d'étendre les actions d'une classe indéfiniment. C'est difficile à expliquer, disons que le fonctionnement fait penser à un plug-in.

---

Désolé, je ne vois pas.

Une interface ne sert qu'à obliger les classes qui l'implémente à présenter les mêmes propriétés et méthodes. Tu instancies ensuite les objets et manipule les interfaces.

A+

Citation:

---

Envoyé par topolino

Il pilote l'interface graphique.

C'est pour cela que l'ui peut etre facilement changé. Il fait la relation entre ce que veux l'ui et ce que lui transmets la BLL

---

J'ai trouvé cet article qui cela en évidence: http://msdn.microsoft.com/fr-fr/magazine/cc337884.aspx

Il s'agit effectivement d'un pilotage. Le controleur génère les pages web en instanciant les classes en fonction des requêtes.

Il faut que j'arrive à cerner l'intérêt. En extrapolant cela reviendrait à n'avoir qu'une seule page ASPX dont le contenu serait généré à la volée?

A+

Je reviens tardivement sur le sujet, je suis en train de regarder de la doc. venant de Microsoft, un PDF : "Web Architecture Pocket". C'est pas mal un document de 145 pages pour de la doc. de poche. Je comprends pas trop ce qui suit :


You should not mix different types of components in the same logical layer. For example, the User Interface (UI) layer should not contain business processing components. Instead, the UI layer should contain components used to handle user input and process user requests

et ça :

For example, a UI processing component should not contain data access code.

Les 2 se rejoingnent. Maintenant il faudrait l'expliquer un truc... Comment ne pas mettre de méthodes d'accès au données ? Je prends un exemple à la con. J'ai une application qui fait une simple division OK ? Tu saisis un nombre et tu mets un autre pour savoir par quel nombre le diviser. Tu cliques sur un bouton OK et hop, t'as le résultat.

L'évènement du bouton devrait contenir un truc comme ça, après avoir converti les données en types "calculables", int float... :

Code:

---

Resultat = Calculs.Diviser(NombreADiviser, Diviseur);

---

Il y a forcément un moment ou on fait transiter les données. Y-a t-il une autre méthode ?

Citation:

---

Envoyé par Aizen64

Comment ne pas mettre de méthodes d'accès au données ?

---

Dans ce cas il s'agit d'accès aux données provenant d'une base et pas du résultat d'une opération.

L'architecture en couche se base sur au moins un principe: une couche ne peux communiquer qu'avec les couches qui lui sont immédiatement adjacentes grâce aux DTO (Data Transfer Objects). Ce sont des classes inertes sans méthodes, elles ne comportent que des propriétés des "accesseurs". Cela permet de découpler les classes et de les rendre plus facile à maintenir.

Citation:

---

You should not mix different types of components in the same logical layer. For example, the User Interface (UI) layer should not contain business processing components. Instead, the UI layer should contain components used to handle user input and process user requests

---

Une interface utilisateur ne fait que recueillir des données de l'utilisateur et présenter celles qu'elle reçoit de la couche métier. J'ai pris pour habitude de faire tous mes développements en console avant de les passer en Web. Ainsi, je ne suis pas dépendant de l'interface. L'interface ne me permet que de faire de l'ergonomie. Mais toutes mes programmes fonctionnent avant en console.

Citation:

---

J'ai une application qui fait une simple division OK ? Tu saisis un nombre et tu mets un autre pour savoir par quel nombre le diviser. Tu cliques sur un bouton OK et hop, t'as le résultat.

---

Il n'y a pas de métier dans une division. Par contre, pour calculer une marge, oui. En console ou en web, le programme te demandera de taper deux nombres: le prix d'achat et le prix de vente.
Si tu n'utilises pas de BLL, tu devras dupliquer le code pour faire ce calcul. Par contre, si tu utilises une couche métier tu transmettras ces deux nombres à la BLL pour obtenir la marge. Le code ne sera pas dupliqué et la maintenance sera facile.

Citation:

---

L'évènement du bouton devrait contenir un truc comme ça, après avoir converti les données en types "calculables", int float...

---

En web

Code:

---

monlabel.Text = BLL.Finance.CalculMarge(prixAchat, prixVente).ToString();

---

En console

Code:

---

Console.WriteLine(BLL.Finance.CalculMarge(prixAchat, prixVente).ToString());

---

C'est la même chose pour la DAL. Seule la BLL est autorisée à communiquer avec. La BLL a besoin d'un jeux de données, une liste de client par exemple. Une fois que le format est determiné (XML, DataTable, List<object>, DataSet, CSV, ...) la BLL ne se préocupe pas de savoir quels moyens la DAL va employer pour se procurer ces données (Web service, base Oracle, SQL, ...). Du moment que tu livres les données que la BLL attend tout se passe bien. Tu peux même changer de source de données en cours de route.

Je te suggère de lire les post "Important" du forum de conception suivant: http://www.developpez.net/forums/f94.../architecture/. Ils sont interessants.
A+

Citation:

---

L'architecture en couche se base sur au moins un principe: une couche ne peux communiquer qu'avec les couches qui lui sont immédiatement adjacentes grâce aux DTO (Data Transfer Objects). Ce sont des classes inertes sans méthodes, elles ne comportent que des propriétés des "accesseurs". Cela permet de découpler les classes et de les rendre plus facile à maintenir.

---

C'est là que j'ai du mal à comprendre leur intérêt et leur implémentation.

Pour en revenir au niveau du MVC, j'ai toujours une idée très obscure de son utilité. C'est dans l'IHM que je récupères les données que je peux utiliser (via les évènements), qu'est ce que le contrôleur vient foutre la dedans ? Dit autrement, si j'ai une classe "Contrôleur", quelles méthodes peut-il contenir ?

Citation:

---

Envoyé par Aizen64

C'est là que j'ai du mal à comprendre leur intérêt

---

Je te cite: http://www.developpez.net/forums/m4109363-2/

Citation:

---

Envoyé par Aizen64

ça serait une bonne idée d'avoir une classe à part qui s'occupe d'exécuter toute opération sur la base de données. Comme ça tu as tout de centralisé.

---

Citation:

---

Envoyé par Aizen64

C'est là que j'ai du mal à comprendre (...) leur implémentation.

---

Rien de plus simple. Pour commencer, une solution .Net vide dans laquelle tu ajoutes:

1. 3 projets bibliothèques de classes nommés ainsi (les noms ne sont pas obligatoires pour que ça fonctionne mais c'est plus clair ainsi):
   
   • BusinessObjects (BO) référençant personne
   • BusinessLogicLayer (BLL) référençant BO et DAL
   • DataAccessLayer (DAL) référençant BO
2. 1 projet application console référençant BO et BLL
3. 1 projet application web référençant BO et BLL

L'ordre de compilation sera automatiquement BO, DAL, BLL, UI

Tu développes en console et tu mets en page en web (ou en winform si tu préfères).
http://www.developpez.net/forums/u33118-a147-i525.jpg
L'architecture obtenue sera celle-ci:
http://www.developpez.net/forums/u33118-a147-i524.jpg
A+

A quoi te sers l'application console ? pourquoi dev en console si c'est pour un site web ?

Citation:

---

Envoyé par topolino

A quoi te sers l'application console ? pourquoi dev en console si c'est pour un site web ?

---

Permet de gager de la qualité de l'architecture car indépendant de l'interface utilisateur. Ce qui marche en console marchera forcement pour le web et le win. Tout le reste est une question de mise en page.

Une révolution http://www.asp.net/mvc/ ?

A+