Discussion :

[Arnard]

J'ai découvert .Net il y a 3 ans pour un projet en 2.0. Arrivant d'un monde Java, j'ai fait la tête au début. Ma première surprise agréable a été la facilité de réaliser des interfaces graphiques en Winform. Bon, si on n'y prend aps garde, on peut vite faire quelque chose de bordélique, mais ça permet d'avancer rapidement ! Mais je ressentais le manque de divers d'éléments sous java, ou des implémentations qui m'échappaient. Bref, ce n'était pas encore ça.

Au passage à la version 3/3.5, avec WCF, Linq et EF (pis WPF/silverlight dans une moindre mesure, je ne les maitrise encore pas), ça a été une révolution. la capacité de communiquer simplement avec WCF, Linq pour le traitement des données (et l'optimisation qui va derrière, un Where coûte moins cher qu'un foreach+if, allez comprendre comment ils ont bidouillé ça xD), ça change la méthode d'aborder un projet, il n'y a plus qu'à se consacrer sur le quoi faire...

En terme de client lourd, c'est un vrai plaisir (pis bon on peut tricher via du bureau à distance pour simuler un client léger portable, qui a dit VNC ?), de développer des applications réactives et ergonomiques. J'ai travaillé sur des projets qui exigent une grande ergonomie et surtout des contraintes techniques fortes, avoir ces technos sous la main est un véritable atout.

WPF coûte cher à l'apprentissage, mais commence à apparaitre dans les produits MS, il suffit de regarder Visual Studio, qui est un assez bon exemple de ce qu'on peut faire, mais qui a du faire s'arracher des cheveux aux développeurs si on repense aux premières betas...

Maintenant, avec la 4.0, massivement parallèle, je sais que c'est un pas en avant, mais par endroit c'est tellement simple de faire un code managé parallèle : avec un appel de méthode supplémentaire, on transforme tout ça (mais pas simpliste, attention aux pièges de la programmation concurrente bien sûr).

Je n'ai pas encore testé l'aspect ASP .Net, aucune idée de ses performances ou le gain qu'il peut apporter...

Un dernier point fort, c'est l'intégration de .net avec les autres produits de Redmond : VS, SQL Server (hâte de développer un ptit soft de surveillance de réplication à plugger), Sharepoint (que je ne connais pas).

Après, ce n'est pas un environnement parfait. Des références nulles qui continuent dêtre la cible d'événements est un élément à connaitre au plus tôt, sous peine de voir son application s'écrouler... On retrouve quelques éléments comme ça qui peuvent empoisonner la vie, et qu'il faut connaître au plus tôt (mais souvent trop tard).


J'avais lu vite fait un article sur l'orentation de .net 5.0, avec du code mutable ou un truc dans le genre, faudra que je le retrouve à l'occaz...

Pour le pourquoi du framework .Net, c'est tout simplement l'avenir de Windows, si on regarde du côté du projet Singularity...

Niveau césure entre chaque version, cela reste très faible, parfois des classes changées d'assemblys, parfois un élément marqué obsolète pour une nouvelle et meilleure implémentation. Dans ces cas là le compilateur fait son office et nous guide au mieux.

J'ai lu un argument pro-.net/anti-java, parlant du fait que java faut se taper 10 librairies tierces à pointer, on peut aussi se retrouver dans cans ce cas avec .net, ce qui sort des labs n'est pas inclus dans le framework, il faut parfois aller piocher sur le site de Microsoft pour avoir ces librairies.

Bon, un post un peu hétéroclite, mais il y a tellement de choses à dire...

[pseudocode]

http://www.microsoft.com/downloads/d...displaylang=en
Il y a un lien "full package" sur la page si tu ne veux pas l'installeur web... mais ça fait 230 Mo
Bizarre

Tu ne pensais pas que je posais la question au hasard, tout de même.

[tomlev]

un Where coûte moins cher qu'un foreach+if

Euh... en termes de lignes de code, oui
Et c'est surtout plus lisible...
Mais en termes de perfs, ça revient au même (pour Linq to Objects du moins), il y a même sans doute un petit overhead dû à l'énumérateur supplémentaire.

Par contre si tu parles de EF, Linq to SQL ou Linq to NHibernate (par exemple), c'est effectivement plus rapide puisque le SGBD pré-filtre les données...

[B.AF]

Ah. Y a la meme chose pour le 3.5 SP1 ? Ca m'intéresse.

Oui mieux, même il est plus léger :
là

[pseudocode]

Oui mieux, même il est plus léger :
là

c'est pas le "Compact Framework" ça ?

[guence]

J'apprécie beaucoup le .NET en utilisation surtout avec C# qui est pour moi le langage pour lequel je suis prêt à laisser tomber mon Delphi. Je pense que M$ a su mettre en place quelque chose qui attire les non java. En attendant la total ouverture.

[davcha]

Tu n'aimerais pas pouvoir faire ce genre de trucs, parfois, B.AF ?

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
var methods = anAssembly.Modules
  .SelectMany(m=>m.Types)
  .Where(t=>t.IsClass && t.GenericArguments.Any(ga=>ga.HasDefaultConstructor))
  .SelectMany(t=>t.Methods);
foreach(var method in methods){
  method.Body.Insert(0, ()=>{Console.WriteLine("blablabla....");}
}

[Hinault Romaric]

c'est pas le "Compact Framework" ça ?

ça c'est bien Compact framework qui est très limité

[tomlev]

surtout avec C# qui est pour moi le langage pour lequel je suis prêt à laisser tomber mon Delphi

Pas étonnant, les 2 langages ont été créés par la même personne
(Anders Hejlsberg)

[Bluedeep]

ça c'est bien Compact framework qui est très limité

Pour l'embarquer dans un téléphone, il vaut mieux qu'il soit compact même si il est limité.

[Hinault Romaric]

Pour l'embarquer dans un téléphone, il vaut mieux qu'il soit compact même si il est limité.

Justement c'est pour ça qu'est prévu le compact framework pour les applications qui vont tourner sur des tablettes pc, des smartphones...

[Bluedeep]

Justement c'est pour ça qu'est prévu le compact framework pour les applications qui vont tourner sur des tablettes pc, des smartphones...

Je sais, je sais : je finalise en ce moment un projet où j'ai 3000 téléphones dans la nature

[B.AF]

Tu n'aimerais pas pouvoir faire ce genre de trucs, parfois, B.AF ?

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
var methods = anAssembly.Modules
  .SelectMany(m=>m.Types)
  .Where(t=>t.IsClass && t.GenericArguments.Any(ga=>ga.HasDefaultConstructor))
  .SelectMany(t=>t.Methods);
foreach(var method in methods){
  method.Body.Insert(0, ()=>{Console.WriteLine("blablabla....");}
}

Si et c'est pour ça que j'aime beaucoup linq to codedom

[davcha]

Et tu peux lire une assembly et la modifier au runtime avec ça ?

[B.AF]

Et tu peux lire une assembly et la modifier au runtime avec ça ?

Non mais tu peux générer du code et le compiler. Disons que tu peux prendre ta DLL, et recréer une assembly en injectant le code dedans.

[davcha]

Ca implique que tu puisses lire ton assembly, ça. C'est ce que je voulais dire, dans la mesure où une assembly compilée (JIT) n'est plus en état d'être modifiée.

[B.AF]

Ca implique que tu puisses lire ton assembly, ça. C'est ce que je voulais dire, dans la mesure où une assembly compilée (JIT) n'est plus en état d'être modifiée.

Oui c'est ce que je te dis. En fait, je m'en sers pour faire des prototypes objets avec des get /set simples, et après avec la réflection et cette API, je créé un projet VS et une DLL qui contient le code 'technique'. Ca me permet de ne pas associer mes problèmes techniques à mes problèmes de modélisation.

Et pour généraliser les comportements, j'utilise des attributs.

Je sais c'est ésotérique, mais c'est après avoir utilisé les T4 et la DSL que je ne trouve pas très productif (je n'ai jamais compris ce besoin de créer des entités graphiquement...Mais bref).

En fait plutôt que d'injecter du code, je fais de l'enrichissement de code pour être exact.

[davcha]

23h58, mal de crâne... J'ai un peu de mal à te suivre.

Donc, tu désassembles une assembly, l'enrichis avec ton truc et la réassemble ?...

Si t'as un exemple concret, je suis preneur.

[B.AF]

Non pas vraiment.

En fait j'ai fais un petit dev maison qui fait la chose suivante :

- Tu crées un projet où tu design ton modéle objet (objets métiers, interfaces, héritages...etc,etc...) en utilisant des POCO
- Dans mon petit Framework, il y a une DLL qui contient des attributs
- J'utilise ces attributs pour tagger ces POCO
du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
    [Persistence(Add|Delete|Update)]
    [WFActivity(Create|Amend|Delete,FullRef|PropertyBased)]
    [WCFService(Create|Amend|Delete, FullRef|PropertyBased)]
    [ComboDto("Id","Name")]
    [BindingBehavior(Notitfy.Self)]
    public class Calendar
    {
        [Key(true)]
        public long Id{ get; set;}
        [GetByProperty(SeekMode.Equals)]
        public string Code{get;set;}
        public string Name { get; set;}
        public void t()
        {
           NullCalendar nc=new NullCalendar();
            nc.addHoliday(new Date());
        }
    }

Après le build, mon petit framework va prendre les classes de cette DLL et en fonction des tag va créer les classes et correspondantes (en génération)
Et dans mon projet réel, je ne vais pas utiliser le modéle ci-dessus, mais les éléments générés.
C'est plus de la génération de code qu'autre chose.
Maintenant, ça peut aussi fonctionner en runtime : tu peux en runtime générer, compiler et exécuter le code.
Dans l'exemple que je te donne, depuis le modéle, je détermine :
- Les query objects
- Les activités WF 4
- Les façades de service
- Les façades WCF (si je veux esposer en rest où autre)
- Les comportements au binding

En fait si je veux changer un comportement où en rajouter un, je l'ajoute dans l'un des modéles et ça s'applique au reste.

J'avais fait ça parce que les générateurs depuis la Db me gêne parce qu'ils sont rarement intelligents, que de designer des POCO depuis la 3.0, c'est piece of cake et ça prend 20 minutes en code, que ça permet d'avoir un projet fonctionnel et de prototyper très rapidement, et d'avoir les outils dont je me sers bien encapsulé. A la fin le développeur ne peut pas modifier les couches techniques et manipule des services et des activités. Tous les aspects techniques (cache, transactions...) sont gérés dans des projets de frameworks à part qu'il peut référencer et pas modifier. Quant aux objets qui lui sont exposés dans les activités, objets, et autres, ils sont sealed de telles façon que si de nouveaux besoins émergent, ont les prennent en compte au niveau le plus bas possible et surtout pour éviter la technique de la "rustine".
En ce moment j'en fait une version 'RDA' qui va créer des MVVM WPF.

Au final, au fil du temps, ça permet très rapidement de créer des couches d'abstraction assez fortes (genre repository, cache...); mais bien maintenues, sans mélange des genres et de générer du vrai code utile et simple pouréviter l'écueil du code généré :souvent difficile à lire.

Peut être que je devrai en faire un truc open source, mais c'est une approche un peu particuliére de la génération de code en fait. Et je l'ai fait parce que les générateurs genre edmx ou mygeneration ne me satisfaisait pas vraiment parce que trop orientés relationnel, et que l'AOP me gênait parce qu'elle laissait toujours des dépendances. Or si tu connais et maitrise tes aspects, ils n'ont finalement pas de raison d'être réalisé en runtime ou au build.

[davcha]

Mais, par exemple, ton framework serait-il capable, au runtime, de modifier le corps d'une méthode ?

Après, le truc gênant, c'est que ton POCO se retrouve décoré avec plein de trucs, en fait.