Bon comme le commentaire est un peu loin, j’ai fait un petit sommaire
L’APPLICATION
Description de l’application
INSTALLATION
Comment l’installer et la tester
DESCRIPTION DE LA CONCEPTION
Le titre parle de lui même
CONCLUSION
Idem
--------------------------- -----------------------------------------------
L’APPLICATION
Voici une petite application permettant de gérer des fiches de connaissance
Ces fiches on un titre et un contenu au format RTF et peuvent être relié à différents critères.
Les critères sont organisés hiérarchiquement :
Par exemple :
Technologie
+--Web
+--Asp
+--Ajax
Langages
+--C#
+--Javascript
Framework
+--Net 1.1
+--Net 2.0
Pour exemple, je veux ajouter une petite source qui concerne une page web asp.net 2.0 en c#. Ma fiche sera donc reliée aux critères suivants :
* Technologie\Web\Asp
* Langages#
* Framework\Net 2.0
Et donc aux critères parents : Technologie, Web, Langage, Framework.
Il est possible ensuite de faire une recherche avec comme critère :
- Le titre
- Le contenu
- Un ou plusieurs critères
INSTALLATION
Le projet devrait normalement fonctionner sans pb mais il vous faut :
- Créer une base SQLServer et y exécuter le script fournit.
- Définir la chaine de connexion dans le ficher app.config
- S’assurer que vous avez les droits sur les procédures stockées. (Les tables ne sont jamais accédées directement)
Ensuite il vous faudra créer des critères :
Menu Outil / Gérer les critères
Pour ajouter un critère (sélection le critère parent ou non puis Fichier | Ajouter (Ctrl+N) )
Une fois que la liste de critère vous convient, fermer le formulaire de gestion des critères.
Menu Fichier -> Nouveau (ou CTRL+N) permet d’ajouter une fiche
Ensuite vous pouvez tester la recherche : Menu Outils | Rechercher | Contenu
(Il est normal que certaines options de menu soient toujours désactivées étant donné que la fonction n’est pas encore développée).
Si vous modifiez la structure des critères alors qu’il existe déjà des fiches, vous pouvez lancer une procédure qui réorganisera les liens Contenu -> Critère en tenant compte que chaque critère liés, doit lier également ses parents.
En définissant TRY_CATCH comme symbole de compilation conditionnelle, vous activerez la gestion des exceptions, mais il peut être utile de le supprimer pour le débogage. (Propriétés du projet / Onglet Générer)
Pour info, tous les try catch sont dans les formulaires (ou rarement, dans le gestionnaire de formulaire). Si vous en trouvez d’autre dans la couche de donnés, les exceptions sont traités puis retransmises à la couche supérieur via un ‘trow’.
DESCRIPTION DE LA CONCEPTION
L’application ne gère que 2 entités (Contenu et Critères) et la conception peut sembler un poil lourde pour gérer aussi peu, donc j’explique pourquoi :
J’ai voulu faire un essai d’architecture avant de me lancer dans une application qui gèrera plus de 50 entités. J’ai voulu me faire ce petit outil (que j’utilise) et en même temps tester cette conception.
Il y a quelques diagrammes de classe dans le projet et le document GIF qui donne une vision globale.
Dans le diagrame GIF les entités n’apparaissent pas sinon le schéma aurait comporté des liaisons dans tous les sens. Il faut savoir que les entités sont utilisées partout car elle transporte l’information de la couche de persistance à la couche de présentation.
Avant qu’on me dise, ‘pourquoi utiliser des entités et non les datasets’, je réponds que je suis contre, car trop lourd, trop liés à l’aspect base de données. Ha si… j’utilise les dataview pour retourner les résultats de la recherche  (dans ce cas, la collection d’entité est trop lourde)
Les entités utilisent le late binding. Cela signifie qu’on ne charge que l’entité et pas les entités dépendantes. .Si vous chargez une fiche (un contenu), les critères qui lui sont liés seront chargés uniquement si vous tenter d’y accéder.
L’application est une MDI avec un menu général.
Le menu concerne toujours la fenêtre qui a le focus. (SI aucune fenêtre n’est ouverte, le menu est grisé (sauf l’option ‘quitter’…)
Les options du menu sont activées suivant la fenêtre active et les interfaces qu’elle implémente (IFrmMenuFile, IFrmMenuEdit ou IFrmMenuTools).
Lors d’un clic sur un élément de menu, mainMdiForm appel le manager pour afficher un éditeur d’instance, un éditeur en arbre, ou un formulaire de recherche. (IFrmEditorInstance, IFrmEditorTree, IFrmSearch)
Le FormManager gère l’affichage et fait en sorte de dialoguer avec le formulaire. Il est la passerelle entre les formulaires et les services d’accès aux données.
Le ProcessManager est un peu particulier, il utilise un backgroundworker lancer le traitement de réorganisation des liens Contenu / Critère (vu précédement pour ceux qui lisent tout…)
Les services sont des classes statiques (sans état). Elles fournissent à la couche de présentation l’accès aux données via des entités, ou des Dataview pour les résultats de recherche.
Les services se charge de vérifier que l’appel est viable et appel les méthodes appropriés pour obtenir ou gérer les données. (C’est ici que l’on place les règles métier, mais le métier pour cette application est assez.. inexistant….)
Les services interrogent le DataProvider qui fournit l’implémentation de l’accès aux données via des interfaces IDBContent, IDBCriteria
Ici ces interfaces sont implémentées pour SqlServer. (c’est paramétrable dans le fichier de config mais seul l’implémentation SqlServer exite). Si vous avez d’attaquer une autre base, il suffira d’implementater les interfaces (IDBContent, IDBCriteria, IDBContentCriteria)