Citation:
Envoyé par
RamDevTeam
1- Quel problème est-ce que ca pose que ce soit du delphi.net ?
Personnellement aucun, mais ce sera du .Net AVANT d'être du delphi et pas l'inverse.
Citation:
2- Qui a parlé de la vitesse ?
D'ailleurs, pour avoir migré une appli win32, en appli delphi.net, je n'ai pas trouvé de différence de performance pénalisante pour l'utilisateur.
Maintenant on n'est pas dans un débat win32 vs .net
Tous les pro-delphi tout au long de ce thread, moi j'ai toujours trouvé que la vitesse n'avait de sens que si le confort d'utilisation s'en retrouvait amoindri.
Citation:
Connais tu précisement ECO pour pouvoir le comparer à d'autres ORM ?
Non et pourtant je m'y suis intéressé lors du choix de mon outil de développement, seulement vu le peu de documentation et de ressources que j'ai pu trouver sur internet à son sujet, je me suis découragé. J'ai au moins découvert que les chaines OCL étaient ni type-safe, ni vérifiées à la compilation et ça me pose un énorme problème personnellement, tu pourras toujours répondre que toi tu t'en fiches mais ce n'est pas du tout mon cas... J'entrerai pas dans le débat pour te prouver que j'ai tort ou raison.
Citation:
Ensuite pourquoi conservé delphi.net ? Une application a un certain cycle de vie et quand les projets sont conséquent, il faut assurer leur pérénnité.
on ne change pas d'outils de dev en fonction de la mode du moment.
Borland (je devrais dire CodeGear), a un principe depuis delphi 1 qui est la "portabilité" de son code de version en version. La compatibilité ne veut pas dire la reprise à 100%, mais en tout cas, peu d'adaptation.
Mais étant donné que delphi.net fait partie de la plateforme .Net dont la spécification est établie par microsoft, ce n'est plus comme en win32 ou borland ou codegear avaient toutes les cartes en main.
Par ailleurs je tiens à signaler que java est un modèle de pérennité lui aussi.
Citation:
Sur les projets que je met en place, je ne veux pas tout mettre à la poubelle quand microsoft décide de faire des changements. Il suffit de voir les pb du passage de vb6 à vb.net pour comprendre ce que je veux dire.
Pour moi, s'enfermer dans une sphère microsoft, c'est ce risque là.
C'est ce que sortent tous les anti-microsoft à tort ou à raison, vb6 et vb.net sont DEUX langages différents à mon sens, le deuxième ayant juste voulu garder la syntaxe familiaire au VB. Pour ce qui est des nouveautés de .Net à venir telles que WPF et WCF, si tu veux continuer à utiliser les winforms et les webservices tels qu ils le sont actuellement c'est ton droit, et ça continuera de fonctionner ainsi. C'est tout de même le développeur qui en général fait le choix technologique en fonction d'un cahier des charges. Notre application est entièrement en framework 2.0 et ce n'est pas parce que les 3.5 arrive qu'on va se sentir obligé de tout passé en WPF, ça marche très bien ainsi, ça tourne sous w2k, sous Xp et sous vista sans problème pourquoi changer?
Citation:
La seul chose qui peux démarquer une société comme codegear, c'est bien évidement d'apporter un gain aux développeurs, que soit via les focntions de l'IDE, via la compatibilité du code, via des fonctionnalités supplémentaires (comme ECO). Alors avoir un peu de retard sur la version de .net est franchement un détail.
Lorsque j'ai procédé a l'évaluation de developper studio, on bossait encore sur le framework 1.1, et vu les enrichissements amenés par le 2.0 sur le plan du remoting et du langage lui-même (support des génériques), ça m'aurait beaucoup contrarié de pas en profiter.