Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Delphi vers C# (VS Studio 2008)
Bonjour, j'aimerais avoir des retours d'expérience de développeurs qui sont passés de DELPHI à Visual Studio 2008 + C#
Plus précisément est-il possible d'atteindre avec VS (Achat des composants en fonction des besoins) la même (excellente) productivité que sous Delphi?
Les développements concernent des applications de gestion SGBD (Oracle et SQL Server).
Hello,
Ma société travaille depuis plusieurs années sous Delphi et Builder et commence à travailler en C#.
Ce que je vais dire n'engage que moi...
Niveau IHM, c'est sans commune mesure. VS surpasse Delphi notamment au niveau de la complétion de code et du debug.
La syntaxe n'est selon moi pas un obstacle à une migration. Même si les noms différent, les concepts restent les mêmes...
Niveau composant, c'est un monde bien plus commercial et si tu souhaites, par exemple, avoir un équivalent du fameux VirtualTreeView, tu devras te tourner vers des éditeurs de composants payants. Le TActionManager et son événement OnUpdate me manque beaucoup également...
D'un autre coté, le framework regorge de classes qu'on aurait bien aimé avoir en Delphi...notamment dans le namespaces System.Collections.Generic. Et le Linq est une vrai révolution.
A tout ça tu rajoutes WCF, WF (et WPF que je n'ai pas encore eu l'occasion d'utiliser), ça fait bien pencher la balance vers VS.
Voilà...si tu as des questions plus précises...
Merci pour tes remarques.
Pour les composants on utilise ceux de DEVEXPRESS (datagrid et autres composants visuels) pour Delphi et ils ont migré sous VS, on les teste actuellement sous cet environnement.
Et justement, quand je compare la facilité de mise en oeuvre de leur datagrid sous delphi et sous VS, eh bien je trouve que c'est plus compliqué sous VS.
Mais sans doute avec un peu d'habitude ... .
Nous développons des applications de gestion et on a des datagrid dans presque tous nos formulaires
Bonjour toricelli,
Je me suis trouvé exactement avec tes interrogations il y a deux mois, et pour ma part la réponse et loin d'être triviale... même aprés avoir ingurgité quelques livres .net et mis en pratique dans les grandes lignes.
Le langage C#: moins structuré que le pascal objet (pas de prototype de méthode à déclarer, déclarations à la volée, etc.) mais le langage est puissant et on s'y fait vite.
Le framework: Excellent, la notion de binding vers objet est puissante, reflection plus riche que les RTTI (mais il faut en avoir l'utilité), trés grande cohérence du framework (due en partie à la richesse des classes de base), globalement trés content du passage à .NET
L'IDE: là, au risque de provoquer quelques réactions, je dirais: attention!
L'approche n'est pas du tout la même qu'avec delphi: MS fournit des wizards qui génèrent du code. Le code généré n'est pas censé être modifié. et le code et peu/pas prévu pour être paramétré. donc on finit par tout ré-écrire à la main... bonjour la productivité. un bon exemple est le wizard ADO.NET pour la création de datasets: on finit vite par soit coder à la main, soit s'appuyer sur un outil de type ORM...
Autre point avec lequel je ne suis pas du tout confortable: peu de composants non visuels, ça ne semble pas être le standard avec VS... du coup c'est plus de code à écrire, certes plus customizable qu'un composant encapsulé et dont on ne modifie que les propriétés, mais là encore c'est un coup à la productivité
Ma conclusion à ce stade (8 sem aprés avoir engagé la migration vers .NET): ces technos ne sont pas comparables et n'adressent pas les mêmes marchés...
Delphi:
L'IDE et l'approche composant de Delphi me semblent bien plus productifs, aidés par des frameworks n-tiers pré-établis (mais qui imposent un modèle d'architecture) tel que DataSnap ou Data Abstract. Plus adapté aux micro-ISV ou éditeurs de logiciels de complexité moyenne. L'absence de binding vers objet rend plus difficile un modèle 3 tiers avec séparation claire data/objet métier/gui
.NET:
Me semble plus comparable à Java/J2EE, outil trés puissant pour développement d'applications n-tiers d'entreprise ou gros logiciel de gestion type ERP, classes trés riches, supporte plus facilement les architectures complexes, mais beaucoup plus de code requis que pour Delphi. Courbe d'apprentissage plus longue du fait de la richesse du framework (sans parler des nouveautés .NET 3.0 et +) couplé à l'approche 'tout code' plutot que 'composant'. Evolution des technos qui peut désorienter (ex: MS pousse à utiliser entity framework plutot qu'ADO.NET, abandon de linq to sql, ...). Pas un outil RAD.
Mettre dans la balance également le prochain Delphi weaver et le projet chromium qui annonce un binding plus élaboré (mais pas de date de sortie annoncée...)
Il ne s'agit que de mon humble avis perso aprés quelques semaines d'apprentissage, avec certainement des points qui sembleront incomplets aux vrais connaisseurs de .NET... vos avis sur ce sujet m'intéresse également!
Puisque nos avis t'intéresse
Tu parles des sections "interface/implementation"...perso, je trouve un peu lourd de devoir dupliquer les entêtes des fonctions juste parce que le compilo n'est pas capable de s'y retrouver tout seul...le pire c'est les warnings que Delphi lance genre "l'implémentation ne respecte pas l'interface" juste parce que t'as pas mis le même nom de paramètre...Le langage C#: moins structuré que le pascal objet (pas de prototype de méthode à déclarer, déclarations à la volée, etc.)
Quant à la déclaration des variables, mêmes si tu peux faire çà n'importe où à la C, rien n'empèche de les regrouper en début de fonction.
Cet inconvénient que tu cites est donc pour moi un avantage.
Tout est ditLe framework: Excellent... non mais comme tu dis plus bas c'est tellement riche qu'il arrive de passer à coté de la classe qui va bien juste parce que tu n'as pas réussi à la trouver dans le magma des classes du framework.
Je n'ai pas encore eu besoin de modifier le code généré. Etrange que tu dises çà puisqu'avec les classes partielles tu peux tout à fait ajouter du comportement à ta classe sans avoir à toucher le fichier généré.Le code généré n'est pas censé être modifié. et le code et peu/pas prévu pour être paramétré
Sinon, pour faire le // à Delphi, je préfére un Designer.cs lisible à un .DFM incompréhensible.
Tu peux tout à fait te créer une biblio de composants...mais c'est vrai que pour une migration, il faut retrouver l'équivalent de tous les composants qu'on avait l'habitude d'utiliser en Delphi...en gros, il faut se refaire sa liste de bookmark.Delphi:
L'IDE et l'approche composant de Delphi me semblent bien plus productifs, aidés par des frameworks n-tiers pré-établis
C'est pas faux, mais le temps que l'on passe à chercher dans la msdn se compense par la richesse du FX qui t'évite pas mal de code et de composant tiers à rechercher.Courbe d'apprentissage plus longue du fait de la richesse du framework (sans parler des nouveautés .NET 3.0 et +)
Bonjour Tetranos,
Ca ne m'a pas semblé aussi trivial... deux exemples:Envoyé par Tetranos
Accés aux bases de donnée:
Delphi: tu crées via l'IDE tes composants et chaîne leurs propriétés: datamodule->sqlconnection->sqldataset. En cas de changement de SGBD tu changes 3 propriétés de sqlconnection
VS: si utilisation du wizard de dataset, le code généré (2500 lignes pour 1 table) utilise des classes spécifiques au provider (oracle, ms sql, ...) (mais pourquoi n'ont ils pas utilisé la dbproviderfactory dans le wizard). la connexion est stockée sous forme d'une chaine dans un fichier de config. pas une approche composant, tout ça... en cas de changement de SGBD, il faut soit re-créer un nouveau dataset, ou se lancer dans une adaptation risquée des milliers de lignes de code générées. Donc mieux vaut utiliser un outil externe d'ORM qui lui génère du code plus indépendant de la base de donnée
Multi-tiers:
Delphi: avec DataSnap 2009 tu chaines également tes composants coté client et serveur. C'est trés rapide à mettre en oeuvre (mais te limites à un modèle d'architecture)
VS: Remoting semble trés puissant, WCF également mais je ne connais pas encore. Le point est qu'il faut tout de même coder à la main le setup du serveur (enregistrer les classes à remoter) et client (de même)
La question de toricelli portait sur la productivité. Sur ce point précis, je n'ai pas retrouvé sous VS .NET la même productivité qu'avec Delphi et Datasnap. Peut être que ce sera la cas aprés + de pratique, d'où ma remarque sur la courbe d'apprentissage. VS a certainement une meilleure productivité sur les architectures plus élaborées/évolutives (en sortant du cadre prédéfini de datasnap): ça dépend donc du produit, et de ce qu'on peut investir en temps...
Y a-t-il sur le forum des micro-ISV qui voudraient partager leur expérience de .NET, en particulier sur la productivité? le choix .NET est il viable dans cette forme d'entreprise (1 à 3 pers) et quelle est la courbe d'apprentissage afin de retrouver une bonne productivité?
Répondre avec citation
Partager