Reprise du message précédent :
 
 
 

Au départ comme tu as dis je voulais gérer ca avec des enums  
Cependant je me suis rendu compte que j'aurais surement besoin dans le futur d'ajouter des caractéristiques ou bien corriger le libellé (par une interface d'administration)
 
Donc je me suis dis je vais mettre ca en base. Cependant si je met tout en base, au niveau du code ca va être une autre paire de manche. Par exemple pour tester le Sexe de l'utilisateur connecté je ne pourrais pas faire CurrentUser.Sexe = EnumSexe.Homme mais je devrais comparer avec un entier.
 
Bref ca commence un peu à me prendre la tête.
 
Sachant que je devrais gérer beaucoup, beaucoup de formulaire contenant les valeurs de ces caractéristiques en DropDownList ou en CheckBoxList ou RadioButton etc...
 
Bref je préfère pas me louper....Je ne sais pas du tout quoi faire
 

 
 
 
Encore mieux avec EF4, un mix des 2 :
 
http://blogs.msdn.com/b/efdesign/a [...] igner.aspx
 

 
Petite nouveauté d'EF 4 entre autre
 
j'étais dégoûté d'être obligé d'utiliser EF 2 quand c'est sorti et que j'ai vu ça

 
 
Yep j'ai vu que c'était supporter mais c'est dans la version CTP June 2011 nan ?
 
En gros elle est encore en BETA cette version de EF si je ne me trompe pas
 

Tention quant même, sauf erreur de ma part, les enums gérés avec EF n'existent que dans la CTP de juin (CTP june 2011), mais n'ont jamais passé en vraie release (comme la gestion des données géographique).
 
Ils ne reviendront qu'avec .net 4.5 (en gros il faudra attendre la prochaine grosse livraison, je dirais avec vs 2011).
 
Pour de la prod je ne me baserais pas sur ce CTP là !
 
quelques explications qui valent ce qu'elles valent
 
Chez nous, on a décidé de se passer de cette CTP, qui ne semble promise à aucun avenir tel quel !
 
EDITH : me dit que l'Update1 n'a pas la gestion des enums...

Pour la déconne : http://channel9.msdn.com/achievements/visualstudio

 
Ha merde j'etait persuadé qu'on en était encore à la CTP de Juin 2011
Bah je vais remplacer mon EF par celui la en espérant qu'il n'y 'ai pas de régression
 
Je vais voir comment il stocke ca. Je suis en Code First donc faut voir si en déclarant un enum il va le stocker directement en base comme une table à part entière.
 
Ca serait vraiment
 
 
 

 
 
Arf Retour au point de départ alors

 
 
Bon bah va falloir trouver autre chose.
 
Donc mise à part une hypothétique nouvelle version (et encore on ne sais pas pour quand) aurais tu un conseil particulier pour mon problème ?
 
Je me retrouve encore plus dans le flou qu'au départ

J'suis encore en 3.5 au taf
 
(Enfin, ma précedente mission, on avait encore 70% des applis en 1.1... )

Cela dit, une petite recherche
 
"faking enum entity framework"
 
devrait aider, c'est à peu près ce qu'on utilise (avec des attributs qui vont bien pour enrichir un peu le bousin (labels))
 
 
C'est certes limité (comme discuté précédemment), mais pour des titres, des sexes, c'est quand même le plus pratique (pas d'ID-qui-ne-veut-rien-dire ou de string dans les requêtes, on aime).

 
Je mélange du 2 et du 4.
 
Le retour au 2 est... surprenant  (mais il est ou mon linq, euh, le truc que je ne pensais jamais utiliser au début)

 
Le pire c'est encore le retour à 1.1... plus de generic... des projets ENTIER de définitions de classes de collections (~300... une pour chaque type d'entite...)
 
PLUS JAMAIS !

 
 
En y réfléchissant bien j'ai pas vraiment besoin d'en faire des enums.
Je peux le faire pour le Sexe, car ca me permet d'avoir plus facilement le sex de l'utilisateur courant.
 
Mais pour ce qui est des caractéristiques d'un profil, a quoi bon avoir un enum dans le code ? Une simple Classe  dans mes Model suffira, car je n'aurais pas besoin (normalement) d'avoir CouleurDesCheveux.Blond dans mon code.  
 
Enfin je pense Je vais avancer on verra bien
 

 
C'est quand même important de réfléchir aux éventuelles requêtes que tu voudras faire...
 
Si par exemple, tu dois chercher uniquement les blonds (ou autre exemple), alors un enum te simplifiera largement la compréhension de ta requête  
 

 
Par contre, si tu dois faire des tris alphabétiques sur la couleur des cheveux, alors il te faudra une classe (ou modifier l'ordre de ton enum pour qu'il ressemble à un ordre alphabétique... pas génial)
Si tu dois avoir les 2, tu devras avoir une classe, et tes requêtes seront chiantes

 
Brèfles, ça mérite réflexion entre maintenabilité et fonctionnalités !

 
 
Ha la tu synthétise mon problème de manière claire j'aime
 
Exactement mais grosso-merdo il y'aura énormément de recherche via des formulaire multicritères
L'utilisateur doit pouvoir rechercher par exemple Toutes les Femmes/Blondes ou Rousses/Entre 18 et 35ans etc....  et j'en passe.
 
Il n'y aura pas de tri par contre je pense, ca n'a pas d'intêret pour mon utilisation.
 

 

 
 
 
C'est vrai qu'il est mieux de convertir avant    
Par contre, tu as clairement la propriété de type Enum dans ta classe (pas stockée en base), et un Wrapper correspondant (entier) , mais tu ne peux pas utiliser l'enum dans une requête linq2entities... puisque EF ne gère pas les enums !

http://www.microsoft.com/learning/ [...] .aspx#tab2

Tu peux faire ce genre de chose :

- Une assembly "ressources" qui contient des enums correspondant à chacune de mes tables de référence. Dans ton cas tu as une table physique "CouleurCheveux" avec un entier en clé, et l'enum correspondant : CouleursCheveux { Blonds = 0, Chatains = 1, Noirs = 2 }

- Une assembly DAL qui référence l'assembly ressources. Comme ça tu peux inclure dans tes requêtes des conditions qui font référence à l'enum :
where personne.couleurCheveux == (int)CouleurCheveux.Blond &&...
Ou encore passer en paramètre ces mêmes enums.
Tu peux aussi utiliser le ToString() de l'étiquette de l'enum si tu en as l'usage.

- Une assembly métier qui référence les deux autres et consomme tout ça

- et d'autres trucs qui viennent derrière (UI).

Seul petit inconvénient : comme "Ressource" est très bas dans la stack tu peux potentiellement être limité pour utiliser certaines ruses visant à étendre les possibilités des enums, comme les Attributes.

Vous avez des liens sur les best practices pour avoir une appli regional settings independant ?

Forcer la CultureInfo.Invariant dans ton appli ? cf http://msdn.microsoft.com/en-us/li [...] lture.aspx pour la référence.
Si appli web (cf mon pb quelques posts plus haut), tu peux setter la culture dans le web.config : http://msdn.microsoft.com/en-us/li [...] 00%29.aspx

EDIT : pour le cas 1, il te faudra setter la CultureInfo du Thread courant (à répéter sur chaque thread si besoin). Je sais pas si c'est possible de setter ça dans un App.config, pas essayé.

Merci.

On peut se certifier à son compte (sans trop de frais) ou bien il faut raquer et à ce moment la vaut mieux y aller avec l'entreprise ?

150€ la certif donc si ta boite paie c'est mieux

ouais mais ça va encore je trouve.
Je m'attendais plutôt à quelque chose de l'ordre du millier d'€ lol

Sinon tu fais comme moi tu les passes en béta, qd c'est gratos

Sinon, je sais pas si y en a ici qui jouent ou ont joué avec Reactive Extensions mais c'est assez fantastique pour tout ce qui est gestion asynchrone d'événements Je débute vraiment dans le truc, ça semble puissant mais spa super facile au premier abord. La syntaxe est super simple, mais les concepts derrière le sont moins, donc je pense qu'il faut un peu de temps pour bien rentrer dedans.
 
Dans tous les cas, tapez-vous le Hands-On Lab, un PDF de 40 pages super bien expliqué avec des tutos et tout. Quelques trucs ont changé par rapport à le dernière version de Rx (GenerateWithTime est remplacé par un overload de Generate, ou FromEvent devient FromEventPattern pour l'overload qui va bien) mais c'est une bonne doc.