Besoin d'aide pour la "conception" d'une couche d'accès à des données XML

Bonjour à tous,

Après avoir lu de nombreux sites / articles / blogs sur comment « bien » ou du moins, mieux structurer une application, je me suis lancé dans le bain pour essayer de prendre enfin de bonnes habitudes.

Je suis en train de créer une application qui doit stocker / récupérer ses données depuis un fichier XML.

Par exemple, concernant l’insertion d’une nouvelle donnée, où doivent se trouver toutes les validations sur l’intégrité de la « clé » de la donnée?

Pour l’instant, dans ma DAL, je fais tous les traitements suivants:

vérifier que le paramètre passé n’est pas null, sinon ArgumentNullException
vérifier que la propriété « clé » du paramètre n’est pas null, sinon ArgumentException
vérifier qu’il n’existe pas déjà un objet avec la même clé sinon DuplicateKeyException
sérialiser l’objet, et envoie une DALException en cas d’exception dans la sérialisation
ajouter l’objet sérialisé dans le XML et l’enregistrer, lancer une DALException en cas d’exception

Est-ce que c’est bien de mettre tous ces traitements dans la DAL ou bien est-ce que certains doivent se trouver à un plus haut niveau?

Ce qui me gêne en faisant ça, c’est que dans ma BLL, j’ai un traitement comme ça quand je veux ajouter un objet:

[code]public static void AddConnection( Connection connection)
{
try
{
DataContext.Add( newConnection );
}
catch (DuplicateKeyException e)
{

	}
	catch (ArgumentNullException e)
	{

	}
	catch (ArgumentException e)
	{
		
	}
	catch (DALException e)
	{

	}

}[/code]

Afin de récupérer les différents cas de plantage et pouvoir afficher un message d’erreur plus explicite…

Comment je peux améliorer tout ça?

Faire en sorte que la DAL ne lance que des DALException me paraît être un bon point déjà, mais dans ce cas, est-ce que toutes les vérifications sur null, sur la valeur de la clé, sur les doublons, etc… vont dans la BLL?

Merci d’avance pour vos avis éclairés :slight_smile:

Mike

Edit: ajout des balises de code

Ne pas considérer XML comme une base de données relationnelle ?

Horst sujet complet mais y en a qui savent ce que tu as fait a Hossegor (et ce que tu n’as PAS fait :)).

En quoi ce que j’ai fait pose souci par rapport à ta remarque?

:crying: On peut savoir? :slight_smile:

Bon, sinon, personne pour me filer un coup de main?

Raaa, Mitsu est à Redmond en ce moment, il t’a montré les photos ? :slight_smile:

[quote=“Zoubidaman, post:4, topic: 37926”]Bon, sinon, personne pour me filer un coup de main?[/quote]De ma maigre expérience, je dirais que tu peut mettre les tests de clé vide ou pas dans ta DAL, on va dire que ça en mange pas de pain.
Par contre le test d’unicité de la clé, celui là, perso, je le mettrais dans la couche métier. Je mettrais donc les 3 premiers cas dans la couche métier. Les deux suivants, portant exclusivement sur l’enregistrement XML, je les laisserais dans la DAL.

Pour ta gestion d’erreur, dans ta DAL dès que tu catch une exception, tu la “throw” au métier. Comme ça, le métier aura aussi connaissance de l’erreur.
Le coup des catch, catch, catch si c’est juste pour de l’affichage IHM, est ce que ça vaudrait pas le coup de mettre un throw direct vers l’interface appelante et c’est elle qui selon le type d’erreur remontée affichera le message voulu. Petit soucis alors : deux méthodes différentes provoquant la même erreur afficheront le même message. Tu peux alors créer tes propres Exception.

Bon voila c’est des idées comme ça. En espérant avoir été clair.

C’est qu’a priori, sauf besoin spécifique que j’ai du mal à imaginer, tu ne devrais pas utiliser de fichiers XML comme stockage. Les SGBDR sont là pour ça avec quantité de fonctionnalités qui vont bien (l’integrité de la clef d’un objet entre autre).
Libre à toi ensuite de rajouter une couche « plus haut » dont le role sera de faire les transformations Objet->XML et XML->Objet.
(comment ca, ca ne t’aide pas du tout ? :slight_smile: )

Utiliser du XML pour stocker des données, c’est pas forcément une hérésie en soit… (c’est utile pour stocker des infos de configuration, garder des données en cache pour des applications partiellement connectées etc.).

Ce qui est déjà plus problématique à mon sens, c’est d’utiliser XML comme un format de stockage relationnel (c’est à dire avec des notions de clés primaires / clés étrangères).
XML permet nativement de matérialiser des graphes d’objets sans passer par des clefs et des références, mais simplement en imbriquant des éléments dans d’autres éléments.

Une autre remarque, c’est que XML supporte relativement mal l’insertion d’entités dans un fichier existant. C’est tout con, mais la plupart du temps, on se retrouve à charger le XML complet, rajouter l’élément dans la liste en mémoire, et re-sérializer entièrement notre liste d’entités.

Dernier point, et non des moindres, en XML, pas d’index. Donc gros volumes = traitements long pour le requêtage (et comme xml est naturellement très verbeux, les gros volumes arrivent vite).

Bref mon point de vue sur XML, c’est que c’est très pratique pour faire des fichiers de configuration, de préférences utilisateurs, ou à la limite pour rajouter des méta-données à une entité stockée dans une table de SGBDR, et surtout pour échanger des informations entre divers application (oui, Web Services SOAP tout ca, j’aime). Mais ce n’est pas un SGBD (service de gestion de base de données), encore moins un SGBD relationnel, et encore encore moins un SGBDR transactionnel.

PS: Mitsu, si tu continues, je balance l’url d’un célèbre magazine de surf allemand :slight_smile:

Mince mes sources sont transparentes :slight_smile:

Je plussoie girafologue. Le XML à utiliser comme base de donnée c’est lourd. Comme il le dit bien, tu va te retrouver à charger tout ton fichier XML puis faire ton traitement (ajout/modif/delete) et enfin recréer ton fichier. L’intérêt de la DAL ici est plus que discutable.
Tu veux pas essayer avec SQLServer Express Edition ? Y’a pas mal de tuto sur le net sur comment se connecter à une BDD (si tu sais pas déjà bien sur :)).

[quote=“zepostman, post:10, topic: 37926”]Je plussoie girafologue. Le XML à utiliser comme base de donnée c’est lourd. Comme il le dit bien, tu va te retrouver à charger tout ton fichier XML puis faire ton traitement (ajout/modif/delete) et enfin recréer ton fichier. L’intérêt de la DAL ici est plus que discutable.
Tu veux pas essayer avec SQLServer Express Edition ? Y’a pas mal de tuto sur le net sur comment se connecter à une BDD (si tu sais pas déjà bien sur :)).[/quote]

Je n’ai vu aucune explication de ce qu’il veux développer donc pourquoi dire que le XML c’est mal. J’utilise moi même le XML dans une de mes applications, il s’agit d’une application Swing qui sauvegarde des fichiers en XML via XStream. Les SGBD ne sont pas une solution pour tous les problèmes.

C’est parce que Zoubidaman a parlé de clef et validation d’integrité.

Oui, en fait je crois que je me suis mal expliqué :slight_smile:

Ce que je veux, c’est enregistrer des informations de connexion en Remote Desktop, afin de faire une sorte de manager pour ceux qui, comme moi au boulot, ont à jongler entre plein de serveurs différents, avec parfois des noms d’utilisateurs / mot de passe différents, etc…

Donc quand je parle de fichier XML et de DAL, c’est uniquement pour ça. C’est peut-être un peu excessif de parler de DAL dans ce cas là, je ne sais pas.

Quand je parlais de « clé » et de « validation d’intégrité », c’est juste que je voudrais faire en sorte qu’on ne puisse pas enregistrer 2 connexions avec le même nom (clé), et je me demandais alors tout simplement où devaient se placer tous ces différents tests: null, unique, nom de connexion vide, etc… Dans la DAL ou la BLL.

Mais à bien y avoir réfléchi, je pense que c’est dans la BLL que tout ça doit se passer, et ne gérer que les exceptions propres au fichier de données ou les exceptions de la sérialisation de mes objets en XML, et renvoyer des exceptions propres à la DAL, afin que la BLL puisse gérer le tout. Ce ne serait donc pas à la DAL de s’occuper de tout ce management de connexion, et si on lui passe une connexion « sans-nom », ben tant pis, c’est pas son souci.

J’ai bon comme ça?

Mon avis sur le sujet :

Oui, c’est bon comme ça.
Maintenant si tu ne prévois de ne faire qu’un “petit” soft, pas destiné à évoluer, il ne faut pas trop se prendre la tête sur des questions d’architecture.
Il vaut largement mieux faire un code robuste et simple que tentaculaire et inutilement complexe.

Je suis tout à fait d’accord avec toi.

Seulement je suis auto-didacte en prog, et jusqu’à maintenant, ça a toujours été du code dans les boutons et autres joyeusetés.

Je profite juste d’avoir eu cette idée d’application pour mettre les choses en pratique, même si ça ne se justifie pas forcément.

Ca me servira pour un autre projet dont j’ai eu l’idée, et pour lequel je veux faire les choses bien comme il faut.

Ta démarche est tout à fait louable.

Bref, pour ma part, je dirai que c’est aussi une question de religion. J’aime bien tout déléguer les vérifications fonctionnelles et la gestion des transactions à la couche BLL et ne faire que les opérations que je qualifie d’atomique dans la couche DAL.

L’idée est que s’il te prends l’envie de changer ta couche DAL, et de passer du XML à un SGBD relationnel ou objet, tu n’es à t’occuper que des opérations les plus simples de lecture, modification, suppression.

Après je suis pas non plus le Grand Architecte… mais pour moi, une bonne architecture c’est une architecture qui s’adapte facilement en cas de changement de techno. C’est d’ailleurs le grand principe des design patterns modernes ( MVC par exemple )

C’est l’idée que je m’en suis fait aussi

[quote=« Monsieur_Max, post:16, topic: 37926 »]L’idée est que s’il te prends l’envie de changer ta couche DAL, et de passer du XML à un SGBD relationnel ou objet, tu n’es à t’occuper que des opérations les plus simples de lecture, modification, suppression.

Après je suis pas non plus le Grand Architecte… mais pour moi, une bonne architecture c’est une architecture qui s’adapte facilement en cas de changement de techno. C’est d’ailleurs le grand principe des design patterns modernes ( MVC par exemple )[/quote]

C’est exactement ce que je voudrais arriver à faire. Isoler le mieux possible les couches les unes des autres…

Un fichier par nom de machine, vérification d’unicité de machine par son nom de fichier, ca évite déjà d’avoir à désérializer / sérializer toute la liste pour créer une nouvelle entrée.

2e avantage, l’intégration au shell windows, pour faire en sorte qu’en double-cliquant sur un fichier, ca ouvre la connexion automatiquement.

(Wouha la feature de la mort que je t’ai glissé juste comme ca ^^)

PS: ah on me dit à l’oreille que le client RemoteDesktop a déjà un format de fichier pour stocker ces données et créer des “raccourcis” remote desktop…

désolé je n’ai lu qu’entre les lignes (mais je vais lire après), mais si tu fais du java, il y a une classe, xmldumper de mémoire qui fait tout ça pour toi…

D’après le A majuscule de AddConnection, ça semble plutôt être du .NET