Discussion :

[heraultj]

Bonjour,

Je sais que pas mal de gens ont déjà dû poser des questions similaires.
Mais je voudrais avoir votre avis sur l'architecture que j'ai créer pour un mini-projet C#.

J'essaye d'obtenir une architecture d'un logiciel qui "respecte" le mieux le MVC.

Je sais que ce n'est pas forcément évident ou que l'on peut toujours s'adapter, mais je voudrais vos avis sur la mienne.

Le projet est disponible en pièce jointe.

Merci d'avance pour vos remarques.

[Invité]

Salut,

Désolé mais je pense l'architecture MVVM (Model - View - View-Model) qui est un dérivé de MVC et de MVP est la mieux adaptée à ton problème et tire de la puissance des liaisons de données et des commandes.

Peut-être tu fais ce test pour juste voir implémenter le pattern MVC sous WPF. C'est ça ?

[heraultj]

Salut,

Je ne parle pas forcément de l'architecture MVC pour le XAML, en effet j'ai pas mal lu à droite à gauche que le MVVM lui siée mieux, mais merci pour l'infos.

Je veux juste obtenir une architecture type MVC pour un projet de logiciel.

[heraultj]

Salut à vous,

Je me pose une question sur l'architecture MVC, je suis toujours en train de tester et la je l'applique à un mini-projet.

Voici mon diagramme de classe (Pas finis de reprendre toute les classes de l'ancien projet MVC) :





J'ai un classe Tiers, si je veux faire un liste de tiers mais plus "light" que la totalité, comment puis-je l'implémenter ici ?

Idem si je peux passer des paramètres à mon modèle, comment puis-je faire ? Sachant que AbstarctModel n'implémente rien de tout cela.

[Luckyluke34]

Bonjour,

Plusieurs remarques :

• Nommage des classes : ce que tu appelles "Model" est pour moi un DAO. C'est le DAO (ou le Repository, etc.) qui est censé exposer les méthodes Add/Delete/Get... pour persister, supprimer ou réhydrater des objets métier d'un certain type depuis la base de données.
  
  Du coup je ne comprends pas trop ce qui est fait dans la classe SqlDAO : les méthodes DataRow/Set/TableGet me semblent être de simples passe-plat de ce qu'ADO .NET fournit déjà, non ? Ca ne fait que remonter d'un cran la fourniture d'objets bas niveau fortement typés SQL/relationnel, je ne vois pas trop l'intérêt...

• La méthode InitWidthDataRow() m'intrigue. Elle semble impliquer que l'objet métier Tiers connait la notion de ligne de données issue d'un stockage persistant, or pour une bonne séparation des responsabilités et une bonne modularité, une entité métier ne devrait pas être couplée à un quelconque mode de stockage.

• Sur l'AbstractController, pourquoi pas, mais attention à l'illusion de vouloir mettre tous les contrôleurs dans le même moule. Ca va marcher pour du CRUD très basique mais beaucoup d'écrans vont vite déborder du schéma standard créer/modifier/supprimer une entité.
  
  Tu seras aussi contraint sur les types que tu pourras utiliser, comme en témoignent tes questions : le contrôleur est obligé de manipuler des types très génériques alors que si c'est un contrôleur de Bidules il aimerait bien profiter de toutes les spécificités de la classe concrète Bidule sans se borner au maigre contrat défini dans la classe abstraite dont hérite Bidule (par rapport à ta question, cette fonctionnalité pourrait être obtenir une liste particulière de Bidules plus restreinte par exemple).

[heraultj]

Bonjour,

Merci pour tes réponses et désolé pour la réponse tardive.

• Nommage des classes : ce que tu appelles "Model" est pour moi un DAO. C'est le DAO (ou le Repository, etc.) qui est censé exposer les méthodes Add/Delete/Get... pour persister, supprimer ou réhydrater des objets métier d'un certain type depuis la base de données.
  
  Du coup je ne comprends pas trop ce qui est fait dans la classe SqlDAO : les méthodes DataRow/Set/TableGet me semblent être de simples passe-plat de ce qu'ADO .NET fournit déjà, non ? Ca ne fait que remonter d'un cran la fourniture d'objets bas niveau fortement typés SQL/relationnel, je ne vois pas trop l'intérêt...

En effet le terme DAO correspond mieux que Model pour nommer mes classes d'accès aux données.
Idem la classe SqlDAO est comme tu le dis une classe de plus à passer pour accéder aux données (dans le but de faciliter la tâche). Je vais donc la supprimer pour simplifier le tout.

• La méthode InitWidthDataRow() m'intrigue. Elle semble impliquer que l'objet métier Tiers connait la notion de ligne de données issue d'un stockage persistant, or pour une bonne séparation des responsabilités et une bonne modularité, une entité métier ne devrait pas être couplée à un quelconque mode de stockage.

C'est la aussi une erreur de ma part (Je suis jeune ), dans le dernier développement que j'ai fait, j'ai pris en compte tes deux premières remarques (citations) en supprimant SqlDAO, en nommant mieux mes classes et en enlevant InitWith...

• Sur l'AbstractController, pourquoi pas, mais attention à l'illusion de vouloir mettre tous les contrôleurs dans le même moule. Ca va marcher pour du CRUD très basique mais beaucoup d'écrans vont vite déborder du schéma standard créer/modifier/supprimer une entité.
  
  Tu seras aussi contraint sur les types que tu pourras utiliser, comme en témoignent tes questions : le contrôleur est obligé de manipuler des types très génériques alors que si c'est un contrôleur de Bidules il aimerait bien profiter de toutes les spécificités de la classe concrète Bidule sans se borner au maigre contrat défini dans la classe abstraite dont hérite Bidule (par rapport à ta question, cette fonctionnalité pourrait être obtenir une liste particulière de Bidules plus restreinte par exemple).

Sinon je viens de trouver ce tutoriel :
http://blog.mazenod.fr/2010/01/desig...-dao-orm-crud/

Je vais le lire pour revoir mon approche. Si vous en connaissez d'autre bon pour expliquer le MVC, je suis preneur.