2009-08-02 12 views
0

Je développe une application Windows Forms. Il a été essentiellement évoqué avec un mélange de BDUP et de prototypage. Je possède environ 1500 lignes de code (excluant la classe partielle générée IDE ... 1465 pour être exact) dans le formulaire et le formulaire a 6 onglets (9 sous-onglets). Il n'y a pas plus de 10 contrôles dans chaque formulaire, de sorte que la solution multi-forme serait une overkill.Refactoring Application Windows Forms

J'ai un ensemble de classes d'entités qui, lorsqu'elles sont sérialisées, me donnent une représentation XML que je stocke dans un fichier XML. J'ai encapsulé ceci avec un modèle de Repository ainsi je pourrais déplacer le stockage à une base de données à l'avenir. Le formulaire utilise les classes d'entités (pour enregistrer/modifier) ​​et la fabrique Repo (ajouter, récupérer et enregistrer). Maintenant, mon problème est qu'une grande partie des 1500 lignes de code traite de l'interaction entre les éléments de l'interface utilisateur (faire un choix dans un combo désactive certains éléments ou affiche différents éléments dans une grille, gérer les transitions de tabulation), le chargement des menus (chaque élément distinct dans le référentiel de fichiers XML devient un élément de menu), nouveau/mode d'édition, etc (j'ai trois ensembles distincts de nouveau/modifier sur la même forme).

  1. Quel serait La meilleure approche ici pour faire sortir l'interaction de l'élément? Disons, je peux décider de faire l'interface utilisateur basée sur le Web à l'avenir
  2. Plus important encore quels sont les refactorings composites que je peux appliquer
  3. Quels modèles dois-je refactoriser à/vers?

Merci de votre aide.

Note: Je lis refactorisation Patterns ... Plus précisément, je voulais avoir un "guide pratique"/conseils sur refactoring pour MVC ...

+0

Vous êtes sûrement excité par les motifs. – Eric

+0

@Eric: Oui, je suis. :) Je comprends sur le plan conceptuel, Séparation des préoccupations est ce que les modèles sont sur. Cependant, il faut un certain temps [même si vous pensez que vous connaissez bien le modèle] pour obtenir l'expérience 'aha' [sachant quand appliquer ce qui peut être très subtile parfois]. –

Répondre

0

Vous devriez regarder dans le Model-View-Controller (MVC) modèle de conception pour résumer votre logique métier à partir de votre logique d'affichage.

Il existe également une autre saveur de la même chose appelée Model View Presenter.

Les deux sont largement documentés sur le net.

Cordialement, Joon

+0

@Joon: Je connaissais le modèle ... Je lis Refactoring to Patterns ... et je voulais avoir un "howto" sur Refactoring à MVC ... J'ai édité la question pour refléter la même chose. –

+0

Vyas - J'ai trouvé que les choses les plus faciles à prendre en compte sont l'accès aux données. Donc, première étape: Mettez tous vos accès aux données derrière un objet d'accès aux données. Ensuite, vous déplacez les appels vers votre DAO pour passer par une classe Model. Vous devez alors déplacer votre logique métier «pure», comme les calculs, les contraintes de validation etc. dans cette classe de modèle. Vous devriez maintenant avoir votre application typique à trois couches, avec front end, couche de gestion et DAO La logique qui reste dans l'extrémité avant vous passez ensuite à une classe de contrôleur, et les widgets de l'interface utilisateur interagissent uniquement avec la classe de contrôleur, qui à son tour accède au modèle. – Joon

+0

@Joon: Oui, pour les applications qui impliquent une base de données et une logique métier (disons, salaire> 60 000 USD avec un bonus de 5%), il est plus facile de démarquer Presentation, Business & Data. Ici, c'est plus de ce que MSFT P & P appelle [utilisé pour appeler?] UI Process components. Je vais en lire plus sur MVP/MVC et publier la session de refactoring sur mon blog. Merci pour votre participation. –

2

Martin Fowler décrit différents modèles d'architecture de l'interface utilisateur dans this article. C'est assez long, mais ça vaut le coup d'être lu. Vous serez alors en mesure de déterminer quels modèles et modèles architecturaux correspondent le mieux à votre scénario.

A la fin de la "Model View Controller" section of that article, Fowler mentionne ces éléments, qui semblent applicables pour vous:

  • Faire une séparation forte entre la présentation (vue & contrôleur) et domaine (modèle) - Présentation séparée.
  • Divisez les widgets GUI en un contrôleur (pour réagir à un stimulus utilisateur) et affichez (pour afficher l'état du modèle). Le contrôleur et la vue ne devraient pas (surtout) communiquer directement mais à travers le modèle.
  • Les vues (et les contrôleurs) observent le modèle pour permettre à plusieurs widgets de se mettre à jour sans avoir besoin de communiquer directement - Synchronisation d'observateur.

Voir l'article et ses liens pour plus d'informations. Bonne chance!

+1

@Chris: J'ai lu ce papier GUI Arch par Fowler assez souvent. Mais égaré le lien quelque part [Ou n'a pas fait une recherche approfondie;) J'ai StackOverflow maintenant]. Merci pour le lien. –

+0

@Vyas: Mon plaisir, je suis heureux que cela a aidé. –