Générateur de code – réflexion
projet personnel
Il faut avouer que Microsoft frappe très fort avec C# 3.0 et Linq
Toutefois je suis toujours à la recherche de la solution « ultime » permettant de gérer ses données et avec Linq il y a encore trop de code à ajouter par soi –même
De plus il y a des inconvénients (qui peuvent aussi etre des avantages mais bon) comme :Le datacontext (pour Linq To SQL) et les classes se trouvent dans le même fichier
Je vais essayer de développer ma propre solution (générateur de code ) j’en avais déjà réalisé un (disponible sur CodeS-SourceS) mais beaucoup trop de contraintes n’étaient pas pris en compte,
cela fait un moment que j’étudie un peu ce qui existe, je vais essayer de m’inspirer de ce qu’il y a de bon dans chaque et d’ajouter ma propre implémentation
- La chaine de
connexion et le provider seront définis dans un fichier de configuration
- Le stockage des
données dans une couche métier n’est vraiment intéressant que pour la consultation en local, évitant des appels au serveur, mais dès qu’il s’agit de faire une mise à jour (Ajout, modification,
suppression) vers la base de données cette couche métier est plus un inconvénient qu’autre chose , mais il faut que je fasse attention car je m’expose à des références circulaires (surtout avec
une architecture n-tiers) si on peut aussi facilement accèder à la couche métier qu’à la couche d’accès aux données
- De plus et c’est dans
la lignée du fait de ce que je viens de dire, stocker l’état des objets (avec notamment un rowstate ou EntityState par exemple) afin de pouvoir ensuite faire une mise à jour de plusieurs lignes
d’un seul coup n’est pas un bien je pense, car on s’expose à beaucoup plus de chances d’avoir des erreurs et leur gestion est rendue plus complexe,mieux vaut essayer de mettre à jour dès
qu’une ligne est modifiée, et en plus utiliser les transactions
- Le mapping par
l’intermédiaire de fichier Xml est mieux que le mapping par attribut . maintenant il faudrait que je gére la génération des requêtes dynamiquement, le risque d’erreur est augmenté par rapport au
code en « dur »
- L’utilisation d’une
architecture n-tiers n’est pas forcément la meilleure solution car il vaut mieux pourvoir accéder à la fois à la couche métier (pour la consultation) et directement à la couche persistance pour
la mise à jour de données, d’un autre côté cela signifie qu’il y aura plus de code dans la couche présentation
- La gestion des
valeurs nulles n’est pas forcément simple car même les nullables ne sont pas forcément adaptés, je devrai donc créer une structure s’en inspirant , car ils permettent d’avoir une valeur nulle
mais une fois une valeur affectée il n’est plus possible de revenir à une valeur nulle
- La gestion des clés
aussi pose des problèmes , surtout les clés auto incrémentées (qui sont définis par le serveur et non l’application cliente) ce qui entraine des risques de générer des clés qui ne correspondent
pas à la clé en base(même le dataset par exemple ne gère pas ce cas et il est très facile de le mettre en défaut), l’utilisation des unique identifiants pourrait être un début de
solution
Bref il y a beaucoup de problèmes auxquels il faudrait que je trouve « la » solution , mais j’avance quand même et cela m’entrainera car peut etre que les outils que met en place
Microsoft fera qu’ils seront la réponse à la gestion des données , il faut avouer qu’ils s’en rapprochent vraiment et qu’utiliser les requêtes Linq est un vrai plaisir
Si le projet arrive à terme, je le posterai sur Codeplex J
