utilité de l'enumbuilder ?

bonjour

juste pour savoir à quoi pourrait servir l'enumbuilder si on ne peut pas l'utilisé en mode design

si quelqu'un a une idée d'un cas concret ...

Salut,

bah comme tout l'Emit, le champ d'application est extremement restreint. Mais etant donné que l'objectif de l'Emit est de pouvoir créer un assembly fonctionnel uniquement par injection d'IL, pour garder une API coherente, ils l'ont rajouté (ca coute pas bien cher, c'est juste une specialisation d'un typebuilder).

Apres, vu que tu peux faire de l'Emit pour sauvegarder un assembly (ca perd enormement de son interet dans ce cas, par rapport à codedom), on pourrait imaginer par exemple une appli qui genererai une DAL à partir d'une DB et qui produirai une enum pour decrire les colones.

Bon, exemple à deux sous, mais AMHA, c'est plus une question de coherence que d'utilité reelle (d'ailleurs, au lieu de faire des enumbuilder, il devrait penser un jour à integrer un delegatebuilder qui serait autrement plus utile =( ).

Bonjour,

SirJulio, tu peux donner des exemples concret d'utilisation de l'Emit ?

Car, contrairement à CodeDom, dont j'ai l'utilité pas quotidienne (loin de là) mais presque, je n'ai jamais eu de cas où utiliser l'Emit et n'ai jamais vraiment compris son utilité réelle. (je ne parle pas de son fonctionnement, mais de son utilité - en dehors de l'écriture d'un compilo .Net, cela va de soit).


Merci.

Son exemple de génération de DAL est très représentatif. Au lieu de générer les sources de l'assembly à partir de la liste des champs/tables (pour ensuite les compiler en assembly), tu génères directement l'assembly en question.

EDIT : Ensuite je ne veux pas trop m'avancer (n'étant pas expert), mais je pense que la programmation orientée aspect est basée sur l'injection de code IL dans les assemblies. Donc ici, ça doit être utile aussi.

Citation:

---

Envoyé par SaumonAgile

Son exemple de génération de DAL est très représentatif. Au lieu de générer les sources de l'assembly à partir de la liste des champs/tables (pour ensuite les compiler en assembly), tu génères directement l'assembly en question.

---

Oui, mais avec CodeDom tu génères aussi très bien sans passer par une phase sources (le seul objet CodeDom orienté réellement "injection de source" est le CodeSnippetExpression).

Citation:

---

EDIT : Ensuite je ne veux pas trop m'avancer (n'étant pas expert), mais je pense que la programmation orientée aspect est basée sur l'injection de code IL dans les assemblies. Donc ici, ça doit être utile aussi.

---

Ok, ca en effet c'est possible (mais je n'y connais rien en AOP).

AFAIK, CodeDom manipule du code source, tandis que Reflection.Emit génère de l'IL, ça me semble assez important comme différence.

Tu peux écrire un compilo avec Emit tandis que si tu essaies avec codedom, c'est un serpent qui se mord la queue.

Donc je t'accorde le point sur la génération de DAL, c'est surement plus facile de le faire avec CodeDom (mais c'est possible de le faire avec Emit).

En regardant dans la MSDN, il est précisé que Emit est principalement utilisé pour de la compilation.

@Bluedeep :

Par exemple, un jour en te levant, tu te dis "Ca serait pratique, si on pouvait gerer toute la logique cross-thread d'une UI simplement, avec un Attribut par exemple" du genre :

Code:

---

1 2 3 4 5

[InvokableMethod] public virtual void FaisUnTruc(...) {   }

---

tu peux resoudre ceci assez facilement avec un pattern Proxy et un peu d'emit. Le principe etant de construire un type derivé de la Form initiale d'overrider toutes les methodes attributées et de leur coller un pattern d'invoke (if (InvokeRequired) {} etc ...) . Resultat, tu n'as plus à te soucier de tes methodes appelables entre thread. Bon bien sur, le BGW reduit ce besoin, et des framework de proxyages de types plutot performant existe deja (dont DynamicProxy de Project Castle).

De maniere general, l'Emit, c'est royal pour faire du proxy runtime (donc ca marche aussi pour proxyer un type inconnu à la compilation genre un plugin). Et l'avantage par rapport à codedom, etant que l'Emit créé directement un assembly, pas besoin de passer au compilateur (qui doit etre un gouffre en perf).

Apres, si tu veux voir plus en details ce qu'on peut faire avec de l'Emit, je te renvoie vers l'excellente serie d'articles (6 à ce jour) de Philip Laureano sur CodeProject, ca te donnera peut etre plus d'idées.

Bon, bien sur, on ne s'en sert pas tous les jours, mais si tu as a t'en servir, c'est reellement extremement puissant.

Edit : Le point aussi entre l'Emit et Codedom est que l'Emit est vraiment emmerdant à ecrire (c'est un langage à part entiere) et à debugger. Pour note d'ailleurs (si tu veux essayer), on peut debugger un assembly emité dans VS avec un fichier texte et deux-trois manip au moment de l'injection, et pour la verification de l'assembly, il existe un outil dans le framework (PEVerify) qui te donnera les erreurs IL.

Citation:

---

Envoyé par SaumonAgile

AFAIK, CodeDom manipule du code source, tandis que Reflection.Emit génère de l'IL, ça me semble assez important comme différence.

---

Pour être précis, CodeDom permet de générer du code source ou d'en utiliser.

Citation:

---

Tu peux écrire un compilo avec Emit tandis que si tu essaies avec codedom, c'est un serpent qui se mord la queue.

---

Absolument mais c'est pour cela que j'ai écrit au dessus

Citation:

---

en dehors de l'écriture d'un compilo .Net,

---

Citation:

---

En regardant dans la MSDN, il est précisé que Emit est principalement utilisé pour de la compilation.

---

Ok, ca répond finalement à ma question.

Citation:

---

Envoyé par SirJulio

Bon, bien sur, on ne s'en sert pas tous les jours, mais si tu as a t'en servir, c'est reellement extremement puissant.

---

Ok, merci pour ces infos :king: