je pense qu'il faudrait déja créer une enum : public enum eWordType { Adjective, Verb, ... }
ensuite créer une propriété dans la classe Noeud : public eWordTpe? NodeType;
nullable pour que les noeud intermédiaires nepossedent pas de valeur mais que les noeuds finaux la possedent.
de plus il faudrait modifier les methodes d'insertion de mots pour qu'ils prennent en compte cette nouvelle valeur.
et pourquoi pas accélérer la recherche avec cette valeur...
d'ailleurs, les noeuds intermediaires devraient peutetre avoir une valeur combinée de l'enum contenant l'enssemble des sous-valeurs pour accélérer la recherche. mais à ce moment la, ca ralentirait l'insertion et modification. donc au choix ;)

salut, je viens de mettre à jour le zip avec la gestion des tables d'association.
j'ai aussi fourni le dump de la base de données de test (MySql).
pour repondre à vos questions, il est vrai que mon projet ressemble à link. d'ailleurs, j'etais bien degouté quand j'ai vu arriver link qui utilisait la meme technique que moi pour les attributs. la mecanique interne, je crois que c'est bien plus evolué que la mienne :p
sinon, oui, le but de ce projet est de ne plus faire de requettes. et meme mieux : le but est de pouvoir changer de sgbdr sans changer le code. changer les noms de tables ou de columns, en n'ayant qu'à modifier les attributs dans les classes de mapping.
autrement, le but de ce programme est d'avoir des objects "normaux", avec des collection d'objects... mais en sql, le schéma est obligatoirement différent (l'exemple avec les voitures) : on doit desfois passer par des tables d'associations.
j'ai l'habitude de devoir travailler sur des bases imposées (mal faites et souvent changeantes) donc mon prog a été pensé pour s'y addapter. si on veut générer les classes avec leurs attributs, il va falloir faire un autre projet et bien déterminer les besoins ;)
en tout cas, merci à vous pour ces commentaires !
j'en attend d'autres par rapport au support des tables d'association ;)
(il serait peut etre aussi utile de remplir des dictionnary<,> mais dans quel ca ? )

pour la question du "RealInsert", je pense que ce n'est pas à mon systeme de vérifier s'il existe ou pas une clef identique. par exemple, dernierement, j'ai eu une "DuplicatedKeyException", et j'etais bien content d'avoir cette exception justement. apres, c'est peut etre au programmeur de faire ces verification, ou meme des try{insert} catch{update} par exemple.
apres, pour les jointures, j'ai reussi à faire quelque chose de pas mal, mais je me pose encore la question des tables d'associations. je depose donc le nouveau zip.

Tmcuh, ce que tu dis par rapport aux "fields", ca me fait grandement penser à un simple DataRow. la raison pour laquelle je n'aime pas les DataRow, c'est qu'il faut connaitre le nom des propriétés en String, et donc à la compilation, on ne peut rien verifier. avec mon systeme, on ne gere que des propriétés donc vérifications à la compilation.
ensuite, si un jour, un champ de la base change, il suffit de modifier l'attribut de la propriété concernée, et rien d'autre ne changera dans le code ! (sauf si on utilisait le nom du champ au lieu d'utiliser des groupes) au fait, pour ca, j'ai aussi modifié le systeme, pour pouvoir donner les noms des propriétés de l'object au lieu de l'appeller par le nom du champ de la base (ce qui donnera des mauvais resultats si ce nom change change).
allez, bientot un update du zip, quand ca sera un peu plus propre pour les jointures ;)

salut salut,
ya d'la bonne idée, la ;)
bon, pour l'instant, j'ai reussi à faire des jointures, mais il faut encore que je rende ca plus maniable : dans nos classes, on a souvent une propriété qui est une liste d'objects, et bien, avec une simple ligne, ca genere la requette, et remplis les objects et listes d'objects. par exemple, dans la classe user, j'ai mis une propriété ville qui a un code postal et un nom. il y a une table equivalente dans la base de données, et quand je lance le programme, ca me remplis bien la ville. j'ai aussi fait le test avec une collection de voitures pour le user, et ca marche ausi. je me pause en ce moment des questions par rapport aux inner join et left join, mais je vais m'en sortir ;)
sinon, il est vrai que pour l'instant, on fait nos objects à la main, ce qui est bien mais pas top. pour ca on peut avoir plusieurs possibilités : regarder la base de données, et générer les classes à partir de ca. mais le probleme, je trouve, c'est que la plus part du temps, les objects et la base, c'est pas la meme architecture : exemple avec une table d'association que l'on a pas dans les objects : on fera juste une List<>. alors quelle est la meilleure solution ? peut etre proposer les deux ;)
ce qui serait idéal, ca serait peut etre de générer les objects à partir d'un xml. et au besoin générer le xml à partir de la base !
à débattre :)

effectivement, pour la puissance des procedures stockées. bien que les curseurs soient lents, ils sont quand meme plus rapides que plein de requettes pour faire la meme chose !
par contre, je peux quand meme faire en sorte de supporter les procédures stockées de maniere simple.
pour l'instant, je continue le programme vers le support des jointures. on verra plus tard pour les procedures stockées ;)
a l'heure actuelle, on peut les executer "a la main" avec mon systeme, c'est deja ca ;)

pour le coté PL SQL par exemple, avec mon systeme on va pouvoir le faire en faisant dans la classe OracleDbMap les override qu'il faut.
ensuite, pour les procedures stockées, au debut j'avais prevu ca, mais je l'ai enlevé car mal géré. mais maintenant, je peux le rajouter, ce sera facile (et mieux géré qu'au début :p )
ensuite, je me suis appliqué pour les perfs : toutes les requettes (gérées avec des iDataParameters) sont stockées et réutilisées au besoin, donc le gros calcul sera fait uniquement pour la premiere des requetes identiques.
aussi pour les perfs, il peut etre lent de faire le tour des GetProperties() d'un object et de recupérer son attribut à chaque requette. pour cela, j'ai géré une dictionary qui stoque les clefs PropertyInfo/DbColumnAttribute. donc c'est aussi amélioré.
alors apres, pour le coup des tables par classe, c'est vrai que c'est pas terrible. seulement, pour l'instant, c'est suffisant. mais effectivement, on va vite avoir desoin de jointures. justement, j'y reflechis. je pense mettre un parametre optionnel à DbColumnAttribute pour specifier la table jointe, avec les conditions de jointure. mais ca ne va pas etre si simple que ca. il faut encore que j'en definisse l'architecture. a voir donc ;)
et ausi, coté code, si certaines choses paraisent floues, n'hesitez pas à me demander :) c'est peut etre aussi que le code n'est pas assez clair, et c'est donc à coriger ;)
Dargos

exactement tmcuh.
en fait, quand on parle de dictionaire, c'est surtout avoir des paires clef/valeur (sinon on va plutot parler de liste).
donc à priori, il faudrait juste ajouter une valeur de type string sur les noeuds '\0'.
quand on va ajouter un mot, on l'ajoutera avec sa valeur : la methode ajouter_mot prendra donc 2 strings en parametre.
ensuite, vu de l'exterieur, on ne devrait pas avoir acces à la mecanique interne de la classe, mais n'avoir que 3 ou 4 methodes publiques comme ajouter, enlever, vider, charger_depuis_fichier. en particulier, on de devrait pas accéder à cette List<Noeud> particulierement dans la signature des methodes.
ensuite, dans le dictionaire, on va le plus souvent demander la valeur d'un mot, et une seule fois loader le dico complet. ce qui serait idéal serait d'avoir une public method qui renvoie une string valeur à partir d'une string clef.pour finir,
pour ca, il va falloir trouver quelle forme donner au fichier, vu qu'on rajoute des valeurs aux clefs : un xml, autres ?
Tmcuh, je suis bien d'accord avec toi pour dire qu'en vitesse acces, c'est surement la methode la plus efficace !
sinon, je vais encore coser un peu la chose :
peux tu predire ce qu'il va se passer si 2 threads ajoutent le meme mot au meme moment ?
si tu comptes laisser la methode ajouter_mot publique, il va surement falloir penser à la synchronisation des threads ! je te laisse y reflechir, mais tu peux te renseigner sur la classe ReaderWriterLock ;)
G33kemenT, Dargos

simple et efficace, j'aime bien :)
par contre, pour etre pointilleux, je dirais que la methode "ajouter_mot" a un probleme :
cette methode est recursive, et elle appelle à chaque fois la methode "existe_mot" recursive aussi. en modifiant de tres peu et en utilisant de preference la methode "est_dans_liste", ca serait surement plus efficace.
ensuite, je ne suis pas tres concerné pas les mots croisés, mais j'utilise souvent des dictionnary pour faire des traductions des textes de l'application. vu ce que tu viens de faire, j'imagine que tu vas proposer une bonne idée ;)

pour ton histoire de multitude de predicateHelper, tu devrais peut etre faire une classe generique genre
public class PredicateHelper<T>{}
ca t'eviterais de reecrire plusieurs fois la meme chose.
tu devrais peut etre implementer l'interface IComparable.. je sais pas..

sinon, pour les List<T>, dans la methode FindAll(predicate(T)) par exemple, tu peux utiliser une syntaxe comme ceci :
int valSup=10;
List<int> MyIntList = new List<int>();
foreach (int myInt in MyIntList.FindAll(delegate(int di) { return di > valSup; }))
{
     Console.WriteLine(myInt.ToString());
}

ce code va tout simplement te sortir les items de ta liste qui sont >10 sans avoir à créer une fonction qui ne servirait qu'une seule fois...

;)