Que choisir ? Delphi ou Java ?

Vous avez raison pour ce qui est des runtimes.
Mais le framework .Net fait partie des windows update depuis un moment déjà, ne pas l'avoir sur une machine devient gentiment plus l'exception que la règle. Les jvm java aussi ont leur place dans un ordinateur multimedia d'aujourd hui.
Que votre programme tienne sur 50mo ou bien 80mo, en entreprise ce ne sera sans doute pas un problème.

Personne ne dira que delphi est un mauvais langage accablé de défauts, mais beaucoup de gens apparemment se font du soucis quant à son future. Ont-ils raison ou pas? C'est difficile a dire.
Si on pouvait juste entendre un argument autre que la vitesse...

Citation:

---

Envoyé par _skip

Si on pouvait juste entendre un argument autre que la vitesse...

---

Vous voulez d'autre arguments en voila:

1. La reprise de delphi par CODEGEAR est un vrai succès avec la sortie de RAD Studio et de delphi 2007
2. Le nouvel IDE permet d'accroitre la productivité et la qualité du code, aide au codage, snippet de code, précompilation, refactoring,
3. Comme tu ne veux pas parler de la vitesse d'exécution parlons de la vitesse de compilation, toujours la meilleure grace au compilateur pascal, non négligeable sur de gros projets privés
4. La palette de composant la plus riche en livraison par défaut, ainsi qu'un nouveau système d'aide au design des interfaces
5. la partie intraweb qui permet a votre exe d'intégrer ou non un serveur web, mais surtout de créer et coder en delphi les pages web, qui seront gérés automatiquement par l'exe qui se base sur AJAX2 et des scripts java. ce qui est puissant lorsque l'on veux ouvrir son appli au web sans rien réécrire.
6. Vous parlez tout le temps du BDE pour les bases de données, mais sachez que delphi fournit bien d'autres objets tout intégrés eux pour accéder au bases de données ADO par example.
7. Pour ceux qui ne sont pas forcément entousiaste pour ADO, je vous conseille les composants gatuit ANYDAC, qui permettent toujours en tout intégré dans l'exe la possibilité d'attaquer toutes les bases de données, et de plus désolé d'en reparler ce sont les plus rapide.
8. L'avenir, l'avenir, mais j'ai vraiment confiance surtout lorsque CODEGEAR annonce dans sa roadmap un avenir multi-platteforme, et oui le projet lazarus (free pascal) le fait bien alors...

Et oui pour ceux qui croyaient que delphi était mort vous vous trompez, c'est peut-être pour cela qu'ils ont appelé le projet delphi 2007, HIGHLANDER... attention à vos têtes elles riqueraient d'être coupées .net

Un language sans mapping objet relationel c'est comme un immortel sans épée.
Rendez-vous dans 2 ans McLeod on verra qui aura survécu ...

Citation:

---

Un language sans mapping objet relationel c'est comme un immortel sans épée.
Rendez-vous dans 2 ans McLeod on verra qui aura survécu ...

---

Sauf que le mapping objet relationnel n'est pas forcément une caractéristique de la structure d'un langage...Donc on peut en faire en Delphi, comme en java ou en php moyennant l'écriture de bibliothèques adaptées ou l'utilisation de frameworks.

Citation:

---

Sauf que le mapping objet relationnel n'est pas forcément une caractéristique de la structure d'un langage...

---

Détrompes toi, ca va devenir le nerf de la guerre :

En java JPA (java persistance API) qui est la spec de persistance.
En .net LINQ qui est l'implémentation de la persistance en .net.


Les framework d'orm en Delphi j'en connais pas (ca existe?) mais ce qui est sur c'est que ca va pas pousser comme des champignons. L'ère du "je code mon mapping a la main" est révolue. D'où le "Rendez-vous dans deux ans".

Je voulais juste préciser qu'on ne parle pas de "langage objet-relationnel" de la même façon que l'on parle de "langage objet" par exemple. L'un est un ajout de fonctionnalité par une bibliothèque tandis que l'autre est une propriété élémentaire du langage et doit être prévu dès sa conception.

Ce que tu cites ce sont des frameworks et non pas des caractéristiques de java ou .net, il n'y a donc aucune raison de ne pas en disposer dans tout langage objet.

Ce type de framework existe sur Delphi à ma connaissance depuis la version 2005 (ECO il me semble).

Il est vrai que je n'ai encore jamais utilisé ce type de framework (à tort ou à raison) car j'utilise ma propre couche d'accès aux données qui me satisfait pour l'instant. A noter (et ça ne s'applique qu'à mon propre environnement professionnel) que ce n'est pas une pratique que je constate très répandue pour l'instant mais peut être la tendance est-elle en train de s'inverser...

Quand tu choisis une plateforme ou un language tu ne prend pas en compte simplement les "propriétés élémentaires du langage" mais aussi "ajouts de fonctionnalités par les bibliothèques". Le spectre de delphi n'évolue plus aussi vite qu'avant et chaque jour le nombre de développeur delphi diminue.

Un conseil pour "assurer" ton avenir, jettes un coup d'oeil à .net.

Citation:

---

Envoyé par heid

Débuter une application Delphi dans un milieu professionel aujourd'hui me parait suicidaire. L'IDE n'existera plus dans quelques années, on fera du delphi.net via visual studio.

---

C'est une affirmation gratuite... Delphi n'est pas prêt de disparaître. C'est un outil d'une qualité et d'une fiabilité remarquables, deux notions qu'on ne peut pas associer avec des produits Microsoft. De plus les programmes Delphi peuvent devenir portables grâce à Lazarus.

En réalité, différents langages et plates-formes peuvent très bien coexister. Dans mon domaine (facturation), Delphi est utilisé pour les IHM, Java pour le middleware, C/C++ pour les traitements...

Citation:

---

Quand tu choisis une plateforme ou un language tu ne prend pas en compte simplement les "propriétés élémentaires du langage" mais aussi "ajouts de fonctionnalités par les bibliothèques". Le spectre de delphi n'évolue plus aussi vite qu'avant et chaque jour le nombre de développeur delphi diminue.

---

La communauté Delphi s'essoufle tu as raison de le souligner mais je crois aujourd'hui que c'est davantage le résultat d'une stratégie brouillone de l'éditeur qui a effrayé les investisseurs qu'à une absence de framework de mapping objet-relationnel performant.

Je connais très bien Delphi et j'ai pas mal bossé sur .net l'an dernier, je travaille en ce moment sur une application web en Java et je n'ai pas considéré les ORM comme une pratique obligée pour construire des architectures solides pour l'instant.

En tout cas on verra dans 2 ans comme tu dis si cela se généralise, je n'ai rien contre mais pour l'instant un simple pattern DAO me convient et je considère toujours Delphi comme un outil hautement productif pour faire du Win32 natif.

Citation:

---

deux notions qu'on ne peut pas associer avec des produits Microsoft

---

vieux troll des familles ;)

Rendez-vous dans deux ans on verra qui avait raison ! C'est en effet un avis qui n'engage que moi. Je ne porte pas de jugement de valeur sur Delphi (que j'apprécie beaucoup) mais un pronostic sur l'évolution du marché. Faites vous une raison (deuil?) et commencez a regarder à coté ;)

Citation:

---

La communauté Delphi s'essoufle tu as raison de le souligner mais je crois aujourd'hui que c'est davantage le résultat d'une stratégie brouillone de l'éditeur qui a effrayé les investisseurs qu'à une absence de framework de mapping objet-relationnel performant.

---

certes

Citation:

---

je travaille en ce moment sur une application web en Java et je n'ai pas considéré les ORM comme une pratique obligée pour construire des architectures solides pour l'instant

---

Dès qu'il y a une base de données c'est quasi obligé de partir sur un ORM ! Je connais aucun projet sérieux qui ferait le choix d'un codage manuel des mapping objet-base. Si tu as 3 tables ok mais imagines avec une 100aine ! De plus le faire a la main multiplie généralement les risques d'erreurs, sans parler de la maintenabilité !

Citation:

---

Dès qu'il y a une base de données c'est quasi obligé de partir sur un ORM ! Je connais aucun projet sérieux qui ferait le choix d'un codage manuel des mapping objet-base. Si tu as 3 tables ok mais imagines avec une 100aine ! De plus le faire a la main multiplie généralement les risques d'erreurs, sans parler de la maintenabilité !

---

La je suis obligé de te soutenir, coder manuellement toutes ses requêtes sous forme de string dans des classes d'accès au donnée pour un projet fortement orienté base de donnée peut vite devenir un cauchemar en terme de temps de développement et surtout de maintenance.
Les ORM actuels permettent de formuler des requêtes sous formes d'objet typés qui sont vérifiés au moment de la compilation, contrairement aux ordres SQL sous forme de string qui eux échoueront au runtime.

C'est précisément la raison pour laquelle je n'ai pas utilisé delphi pour mon dév actuel, j'ai pensé à ECO mais malheureusement je n'ai trouvé que peu de documentation et j'ai cru constater qu'il n'était utilisable que pour la version .Net et non la win32.
Donc quitte a faire du .Net, autant employer C# et visual studio 2005.

Citation:

---

coder manuellement toutes ses requêtes sous forme de string dans des classes d'accès au donnée pour un projet fortement orienté base de donnée peut vite devenir un cauchemar

---

Je suis sur un projet d'une 100taine de tables maxi et ça se passe bien, j'arrive à maintenir un certain niveau de qualité et de souplesse et en tout cas à répondre aux exigences de ma hiérarchie. Maintenant je n'écris une classe de DAO que pour les objets métiers nécessitant des traitements complexes, dans les autres cas c'est encapsulé dans un traitement générique ("type" databinding) donc la manip se fait au coup par coup et plutot sans douleur je trouve.

Je cherche naturellement à faire mieux et d'après ce que je lis, le passage par un framework O/R est quasi obligé. Je ne pourrais pas vous contredire, je ne connais pas suffisamment ce type d'outils même si j'arrive à m'en passer pour l'instant. Je vais surement m'y mettre pr mes futurs projets Java.

Citation:

---

Je connais aucun projet sérieux qui ferait le choix d'un codage manuel des mapping objet-base

---

Moi non plus pour le codage manuel, par contre j'ai vu bcp de projets très sérieux (sur plusieurs centaines de tables et des millions de données) ne pas faire de mapping O/R du tout, c'est ce que je voulait souligner.

Citation:

---

Donc quitte a faire du .Net, autant employer C# et visual studio 2005.

---

C'est sûr. Delphi aura toujours un train de retard sur la VSXXX de toute façon.

Citation:

---

Je suis sur un projet d'une 100taine de tables maxi et ça se passe bien, j'arrive à maintenir un certain niveau de qualité et de souplesse et en tout cas à répondre aux exigences de ma hiérarchie.

---

Bien sûr ce n'est pas du tout impossible, surtout si le projet a été bien réfléchi et bien cadré au départ. Cependant, sur un grand projet, ça résoud pas mal de situations difficiles quand on en vient au refactoring et aux adaptations du schéma de donnée.

Et puis on le fesait bien avant !

Citation:

---

En .net LINQ qui est l'implémentation de la persistance en .net.
Les framework d'orm en Delphi j'en connais pas (ca existe?) mais ce qui est sur c'est que ca va pas pousser comme des champignons. L'ère du "je code mon mapping a la main" est révolue. D'où le "Rendez-vous dans deux ans".

---

Pour les applications delphi.net, ca s'appelle ECO .. et il n'a rien à envier à LINQ, bien au contraire.
Hibernate, bien connu dans le monde java existe aussi en version .net

Pour les Applis Win32, il y avait Bold (j'ai pas testé, donc je ne sais pas jusqu'ou il va).

Concernant LINQ vs ECO :
Une discussion à ce sujte sur le forum Borland :
http://groups.google.fr/group/borlan...74073cb1b05f42


Je recite les quelques points de comparaison évoqué :

Citation:

---

1) Entity inheritance:

Linq to SQL - NO
Linq to Entities (beta) - YES
ECO - YES

2) Many-to-many associations between entities:

Linq to SQL - NO
Linq to Entities (beta) - YES
ECO - YES

3) UML compilance (modeling entities as classes, not tables):

Linq to SQL - NO
Linq to Entities (beta) - NO
ECO - YES

4) DB schema generation from high-level entity model:

Linq to SQL - NO
Linq to Entities (beta) - YES
ECO - YES

5) Linq support (quering directly with C# language)

Linq to SQL - FULL
Linq to Entities (beta) - FULL
ECO - PARTLY (in-memory only)

6) OCL quering:

Linq to SQL - NO
Linq to Entities (beta) - NO
ECO - YES

7) In-memory undo/redo features:

Linq to SQL - NO
Linq to Entities (beta) - NO
ECO - YES

8) Executable state machines:

Linq to SQL - NO
Linq to Entities (beta) - NO
ECO - YES

---

Oui mais c'est du delphi .NET
Donc argument vitesse -> poubelle.
Donc version framework .Net dépassée
Donc documentation et communauté très en dessous de c#

Et tout le reste quoi, Qqn a parlé de linq mais il existe des dizaines de mappers d'objets en c#, dont certains extrêmement puissants qui génèrent des entités entièrement sérializable, remotables et avec des système de requête fortement typées de n'importe quelle complexité (gros avantage d'un ORM).
Et avec lesquels 100% du code DAL est checké lors de la compilation.

Franchement j'ai beaucoup de mal, en faisant preuve de toute la largesse d'esprit possible à comprendre pourquoi on pourrait préférer Delphi.net aux autres langages de cette plateforme si ce n'est pour conserver ses habitudes de codage.

1- Quel problème est-ce que ca pose que ce soit du delphi.net ?
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

Citation:

---

Et tout le reste quoi, Qqn a parlé de linq mais il existe des dizaines de mappers d'objets en c#, dont certains extrêmement puissants qui génèrent des entités entièrement sérializable, remotables et avec des système de requête fortement typées de n'importe quelle complexité (gros avantage d'un ORM).
Et avec lesquels 100% du code DAL est checké lors de la compilation.

---

Connais tu précisement ECO pour pouvoir le comparer à d'autres ORM ?

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.

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à.

Je continue à faire le pari que l'évolution de mes projets est facilité par un environnement de développement qui fait l'interface entre les changements de framework et mon code. Microsoft n'a pas besoin de se pencher sur la reprise des versions antérieurs, c'est aux développeurs de s'adapter aux changements.

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.

RamDevTeam tu peux aujourd'hui continuer a développer en delphi sur le framwork .net 2.0 ce qui te permet de penser que ton appli est pérène au niveau des évolutions.

Mais dans 5 ans? penses tu vraiment que code gear migrera delphi vers le framework 3 ? intègrera le wpf et le wcf? Moi non. Et la tu sera sur ton petit morceau de glace qui apartenait avant à la banquise mais qui s'est détaché : dérivant au milieu de l'océan tandit que la taille de ta communauté rétréciera au fur et à mesure...

Certes tu peux migrer tes applis delphi en delphi.net mais a ta place je réfléchierais à deux fois avant de débuter un nouveau projet en delphi.

Qu'apporte Delphi.net par rapport à visual studio + c#? Pourquoi utiliser un language moins répandu (isolé?), qui à deux ans de retard sur les framework et dont l'avenir est incertain ?

Je suis heureux de savoir que tu fais parti de CodeGear ce qui te permet de nous donner la roadmap de Delphi pour les 5 années qui se présentent.

Je trouve que tu veux enterrer beaucoup trop vite codegear et aussi que tu sous-estime largement la masse des développeurs delphi.
Pourquoi est-ce que la vision européenne et si différente de la vision outre-atlantique ?

Quand Borland a annoncé qu'il se séparait de l'activité IDE il y a eut 2 types de réactions :
En europe : tout le monde à crier, "Ca y est delphi est mort"
Au états-unis : La majorité a dit "Enfin, delphi va être repris par une structure qui va le refaire évoluer, il était temps".
La suite ne ressemble pas du tout à ce que tu essaie de dépeindre. On voit bien un retour en force de CodeGear. Bien sûr il y a un retard accumulé à rattraper, mais il y a une réélle volonté de faire des produits pour les développeurs.

Pour ta question, est-ce que mon code migrera dans 5 ans vers le framework 3.x ou 4.x, est-ce qu'il intègrera le wpf et le wcf?

Je pense que les interfaces utilisateurs créer avec delphi auront largement plus de chance de pouvoir migrer que les winforms ...

Figure toi que j'ai bien réfléchis avant de débuter les nouveaux projets.
Je ne garde pas delphi par nostalgie du passé.
Mes nouveaux projets sont gérés comme suit :

- IHM de type VCL.NET, + séparation en package
- Assemby C# pour la partie métier
- ECO en C# pour la couche ORM

Quand à la version en décalage du framework, ca ne pénalise en rien mes applications.