Déclaration des présentateurs et des vues

Question

Je crée une application WPF comprenant des écrans (Presenter + View). Je veux pouvoir déclarer ces écrans dans un fichier de configuration ou une base de données SQL. J'ai essayé de trouver une bonne solution que j'ai abandonnée et je me demande comment certains d'entre vous conçoivent ce genre de chose? J'y travaille depuis plus d'une semaine et toutes les solutions que je trouve pue.

Dans mon application WPF, j'ai une vue arborescente qui représente les écrans. Lorsque l'utilisateur clique sur un nœud, l'écran est chargé. Je veux être capable de remplir les treenodes à partir d'un fichier de configuration ou d'une base de données. Le programme ne devrait pas se soucier où ils sont stockés afin que je puisse échanger un magasin de configuration pour un magasin de base de données. Si les informations sur l'écran sont stockées, je peux également utiliser un conteneur IOC pour instancier les écrans et les récupérer par nom. Voici un exemple du schéma de fichier de configuration que je suis venu avec:

<screen name="" title="" presenterType="" viewType=""/> 
<screen ...> 
    <screen .../> 
    <screen .../> 
</screen> 
<screen .../> 

La dernière solution que je suis venu avec est d'utiliser un ScreenService qui demande un ScreenRepository pour les objets screeninfo. Ensuite, je serai en mesure de remplir le conteneur treeview et IOC avec cette information.

Cela vous semble-t-il une bonne solution? Que feriez-vous différent? Et, comment concevez-vous ce type de système dans votre propre programmation?

Answer 1

Lorsque vous renvoyez des objets à votre méthode d'usine, vous pouvez également inclure une hiérarchie. Par exemple mes usines de forme ont deux méthodes On retourne une liste de formes qui ont été ajoutées à une liste principale, Un autre renvoie des bibliothèques de formes. Alors que l'utilisateur peut définir et modifier les bibliothèques réelles, j'ai un ensemble par défaut généré automatiquement à utiliser pour le dépannage et l'installation initiale. C'est hiérarchique.

Toutefois, une bibliothèque ShapeLibrary est composée de ShapeLibraryItem. Un ShapeLibraryItem a une clé stockée avec lui afin qu'il puisse tirer la forme hors de la liste principale du programme. Donc, un bouton ou un élément est cliqué, il regarde l'article ShapeLibrary auquel il est associé. Obtenir la clé, utilise la clé pour obtenir le programme de forme, puis utilise l'interface utilisateur pour dessiner l'écran.

Si votre écran contient les informations de hiérarchie incorporées dans l'une de ses nombreuses propriétés, nous vous recommandons de les séparer dans un élément de hiérarchie. Une HierarchyList peut alors être créée, composée de HierarchyLists OR HierarchyItem. Je ferais une interface IHierarchyItem pour que HierarchyLists ressemble à un élément.

La principale différence est le comportement. Lorsque vous cliquez sur un HeirarchyList fera apparaître une autre liste (ou développer, etc) un vrai élément fera apparaître un écran.

Votre assemblage aura donc deux classes marquées avec l'un des deux attributs. L'un sera ScreenFactory et l'autre sera HierarchyFactory.

Notez que vous n'avez pas besoin d'utiliser les clés pour lier directement un élément HierarchyItem à la forme. J'utilise les touches GUID pour éviter le couplage à chaque fois. Le couplage n'est pas toujours mauvais mais ce n'est pas toujours bon non plus. Puisque les GUID sont effectivement uniques, ils fonctionnent de la même manière. En ce qui concerne la performance, vous aurez des centaines d'assemblages avant de le remarquer. Rappelez-vous que vous n'avez pas besoin d'avoir un assemblage pour chaque écran. Il suffit de les regrouper logiquement dans une poignée d'assemblées et vous êtes prêt à partir.

Answer 2

En général, vous devez utiliser un motif d'usine pour ce type de situation. Votre mélange de ScreenService, ScreenRepository, et Screeninfo sonne comme si vous l'aviez cloué. Here est un aperçu de base de ce qu'est un motif d'usine. Vous pouvez utiliser l'article Wikipédia comme point de départ pour voir s'il y a des variations ou des aspects que vous avez manqués.

J'ai conçu et maintenu une application de CAO/FAO qui a plusieurs bibliothèques de formes paramétriques prédéfinies où l'utilisateur peut saisir quelques dimensions et calculer la forme pour la coupe. Chaque forme a sa propre configuration d'écran. J'utilise un modèle similaire à votre lors du démarrage de mes applications.

Je scanne le répertoire de la bibliothèque de formes pour chaque assemblage, sélectionne la classe de fabrique qui a une méthode qui récupère une liste de formes, la charge dans une liste principale. Lorsque l'utilisateur clique sur un bouton de la barre d'outils ou choisit dans la liste, le logiciel utilise ensuite une clé pour sortir la bonne forme de la liste qui expose une interface IShapeScreen. Le formulaire qui gère les formes utilise cette interface pour dessiner l'écran d'entrée correct pour cette forme.

Cette méthode a fonctionné pendant presque une décennie sans problèmes significatifs et tout aussi important ne m'a pas laissé avec un sentiment de "Oh je souhaite que je l'ai fait quand je l'ai conçu". Donc je pense que vous êtes sur la bonne voie.

Notez que vous n'aurez peut-être pas besoin d'utiliser un fichier de configuration basé sur du texte. En utilisant des attributs, certaines interfaces que vous définissez et l'API de réflexion .NET, vous pouvez simplement lancer des DLL dans un répertoire, le logiciel peut analyser ce répertoire et insérer correctement les objets souhaités. Dans vos objets d'écran de cas. Cependant, si vous voulez qu'un humain édite la configuration, un fichier texte est certainement nécessaire. Je suppose que vous utilisez l'API .NET que vous étiez étiqueté avec .NET.

Answer 3

Désolé, j'aurais dû mentionner que j'utilise .NET 3.5. Je suis tellement habitué à publier sur le forum ASP.NET que j'ai oublié. J'apprécie le scan de l'idée des assemblages, mais je voudrais qu'il soit défini comme une hiérarchie pour peupler l'arborescence. En outre, quelle est la pénalité de performance pour l'utilisation de la réflexion pour analyser les assemblées par rapport à un fichier de configuration ou une base de données? Est-ce une différence notable ou si mineur que personne ne pourra le dire?

L'application que je crée doit être utilisée en interne dans notre entreprise.Il doit avoir une structure hiérarchique pour la navigation afin que nos écrans soient faciles à trouver. L'analyse d'un dossier d'assemblage serait bien, car nous pourrions faire un module et à travers dans ce dossier et l'application le ramasserait automatiquement. Cela conduirait à un problème de représentation des écrans de manière hiérarchique. En outre, nous souhaitons implémenter l'autorisation afin que les utilisateurs ne voient que les écrans qu'ils sont autorisés à utiliser.

Merci pour la réponse. J'aime voir comment les autres font les choses. Cela m'aide à comprendre beaucoup de ces concepts puisque je ne fais que commencer sur le chemin des modèles de design (juste commandé le livre PEAA). Quelqu'un d'autre s'il vous plaît partagez vos pensées. Cela peut aussi aider quelqu'un d'autre comme moi qui trébuche sur cette question.