Portage d’une application PowerBuilder vers .NET

Quand j’ai vu le titre, j’allais juste me cacher, étant un célèbre bigot de PB. Tant pis. Merci pour le vote de confiance, Bernard.

Ma première suggestion serait d’abandonner le langage de l’auto-illusion. Si je mange la moitié d’un gâteau au fromage “allégé”, je vais encore perdre de vue ma ceinture. Une migration peut prendre aussi peu que 10 minutes. Ce que vous allez faire est une réécriture . Le temps doit être mesuré comme une réécriture. Le risque doit être mesuré comme une réécriture. Et l’ effort de conception doit être mesuré comme une réécriture.

Oui, j’ai dit effort de conception. “Migrate” crée des images de code de pompage dans une boîte noire avec une traduction reflétant l’original sortant de l’autre côté. Voulez-vous reproduire les mêmes erreurs de conception que celles que vous aviez commises en 1994 et que vous vivez depuis des années? Même avec un code de qualité excellente, je suppose que d’excellents choix de conception dans PowerBuilder peuvent être des choix de conception terribles en C #. Une conversion directe néglige-t-elle le pouvoir et les forces de la plate-forme? Allez-vous vivre avec les conséquences de négliger un bon design C # pour les 15 prochaines années?

Hormis cela, puisque vous ne parlez pas de votre motivation pour passer à “.NET”, il est difficile de suggérer les options que vous pourriez avoir pour atténuer le risque de réécriture. Si votre direction a simplement décidé que les développeurs PowerBuilder avaient une mauvaise odeur et devaient être supprimés du bureau, alors bonne chance pour la réécriture.

Si vous souhaitez simplement déployer des services Web Windows Forms, Web Forms, Assemblys ou .NET, ou exploiter les bibliothèques .NET, alors, comme l’a mentionné Paul, passer à 11.0 ou 11.5 pourrait vous permettre d’atteindre ce but, avec un effort plus proche d’une migration. (Je suggérerais à nouveau de revoir et de vous assurer que la nouvelle plate-forme est bien conçue, en particulier avec Web Forms, mais que cet effort devrait être beaucoup moins important qu’une réécriture.) Si vous souhaitez déployer une application WPF, je sais attendre un an est un peu long, mais il vaut peut-être la peine de chercher dans PowerBuilder 12. Utilisée correctement, la fonctionnalité WPF peut placer PowerBuilder dans une position unique et puissante.

Si la réécriture est garantie dans votre avenir (les douches semblent moins chères), vous voudrez peut-être mettre en phase la conversion. DataWindow.NET permet de prendre vos DataWindows avec vous. (Ma théorie de l’animal de la semaine est que les développeurs de PowerBuilder tiennent le DataWindow pour acquis jusqu’à ce qu’ils soient obligés de reproduire toutes les fonctionnalités intégrées.) Une interface utilisateur dynamic consommant des ressources, imprimable et liée aux données, générant un minimum de SQL avec le locking d’enregistrements logiques intégré et la conversion des erreurs de firebase database en événements, dans une nouvelle application est un avantage considérable.

Vous pouvez également mettre en phase la transition en convertissant votre code PowerBuilder en un élément consommable par une application .NET. Comme mentionné précédemment, vous pouvez produire des objects COM avec le PB 10 que vous avez, mais vous devrez passer à 11.0 ou 11.5 pour produire des assemblages. La valeur de cela peut dépendre de la qualité de la partition de votre application. Si votre logique métier parcourt les événements et les fonctions de l’interface graphique au lieu d’être partitionnée en objects non visuels (classes personnalisées), sa valeur peut être discutable. Néanmoins, il s’agit d’un faux pas qui devrait probablement être corrigé avant une conversion complète en C #; c’est une chose qui peut être faite tout en maintenant l’application PowerBuilder en tant qu’étape préliminaire pour une conversion progressive, puis complète.

Nul doute que je préférerais que vous restiez avec PowerBuilder. À défaut, j’aimerais vous voir réussir. N’oubliez pas qu’une fois que vous avez pris votre première bouchée, vous devrez la finir .

Bonne chance pour trouver cette ceinture,

Terry

Je vois que vous avez mentionné le déplacement des “composants principaux” vers .NET pour commencer. Comme vous pouvez le deviner, je pense qu’une approche par étapes est une sage décision. La définition de “kernel” peut maintenant être discutée, mais qu’en est-il d’un sharepoint vue contraire? Nourriture pour la pensée? (Évidemment, ce n’était pas la bonne semaine pour commencer un régime.) En fonction de l’état actuel de PB, il serait difficile de diviser votre application entre PB et la fonctionnalité d’application (par exemple, comptes clients dans PB, comptes fournisseurs en C #). Une division qui peut fonctionner est une interface graphique ou une logique métier. Comme mentionné précédemment, le pompage de la logique métier de PB vers les exécutables que C # peut consumr est déjà possible. Pourquoi ne pas construire l’interface graphique en C #, avec DataWindows copié à partir de PB et la logique métier pompée sous forme d’objects COM ou d’assemblages? Dans l’autre sens, pour utiliser des assemblys .NET dans PB, vous devrez soit déplacer jusqu’à 11.x et migrer vers Windows Forms, soit les placer dans un wrapper appelable COM .

Ou bien, formez simplement vos développeurs C # à PowerBuilder. Cela pourrait bien être une rumeur, mais j’entends dire que le nouveau slogan marketing de PowerBuilder sera “Si simple, même un développeur C # peut l’utiliser.” 😉

Je pense que gbjbaanb vous a donné une bonne réponse ci-dessus.

Quelques autres questions à considérer:

• Cette application PB10 est-elle une nouvelle application PB10 bien écrite ou a-t-elle été créée en 1998 dans PB4, puis progressivement convertie en PB10 au fil des ans? Une application bien écrite doit comporter une ségrégation décente entre la logique métier et l’interface graphique, et vous devez pouvoir systématiquement transférer votre code vers .Net. Au moins, cela devrait être beaucoup plus facile que s’il s’agissait d’une application PB héritée, auquel cas il serait probable que vous ayez des tonnes de logique enfouies dans les boutons, les fenêtres de données, les menus et qui sait quoi d’autre. Pas impossible, mais plus difficile à retravailler.
• Comment fonctionne l’application? Si c’est correct et stable, et n’a pas besoin de beaucoup de nouvelles fonctionnalités, alors peut-être qu’il n’a pas besoin de réécriture. Ou, comme l’a dit gbjbaanb, vous pouvez placer des enveloppes .Net autour de certains éléments, puis exposer les fonctionnalités dont vous avez besoin sans une réécriture complète. Si, en revanche, votre application est réfractaire, désagréable, ne satisfait pas vraiment les besoins de votre entreprise et rend vos utilisateurs inefficaces, vous pouvez alors plaider en faveur d’une réécriture, ou peut-être d’une refactorisation sérieuse, puis de quelques améliorations. Il y a des gars de PB qui purgent des peines, euh, je veux dire, qui gagnent leur vie avec le deuxième scénario.

Je ne suis pas contre les réécritures si le logiciel est extrêmement pauvre et affecte négativement les activités de l’entreprise, mais même dans ce cas, les ajustements et améliorations progressifs constituent un moyen moins risqué de faire évoluer le système.

Ne vous fiez pas à la discussion sur ce sujet tant que les messages de Terry Voth n’auraient pas été publiés. Il est sur StackOverflow et est l’un des meilleurs gars de PB.

Si sa taille est assez grande, vous obtiendrez peut-être de meilleurs résultats en écrivant un serveur frontal au format .net (ou une interface graphique Web) et en l’utilisant pour interagir avec votre code PB, en supposant que vous puissiez exposer la fonctionnalité sous forme d’API.

Si vous utilisez PB 9 ou une version ultérieure, vous pouvez générer des dll COM ou .NET que vous pouvez ensuite utiliser avec une interface graphique C #. Je le recommanderais plutôt que de réécrire dans une nouvelle langue.

N’oubliez pas que les réécritures ne sont jamais une solution miracle, elles finissent toujours par prendre plus de temps, plus de temps et plus de bogues que vous ne le pensiez.

Vous voudrez peut-être consacrer un peu de temps à l’parsing de PowerBuilder 11.5 (récemment publié), qui ajoute une importante intégration .NET.

Migrer vers PowerBuilder 11.5 pour utiliser le nouveau code .NET sera certainement beaucoup plus facile que de réécrire complètement l’application entière en C #.

Je ne sais pas si c’est bon ou non, mais vérifiez ce produit (commercial): PB.Net

Ma théorie de l’animal de la semaine est que les développeurs de PowerBuilder prennent DataWindow pour acquis jusqu’à ce qu’ils soient obligés de reproduire toutes les fonctionnalités intégrées.

Je soutiendrais cette théorie. J’ai tenté une tentative de conversion de PB8 à Java sur un projet il y a plusieurs années, qui a lamentablement échoué, même en utilisant le HTML de première génération, DataWindow. Mon employeur actuel a la ferme intention de passer à C # et de ne pas utiliser Datawindow.NET malgré plus de 2 000 fichiers DWO dans notre produit actuel. Je n’attends pas avec impatience le jour où la réalisation commencera. (Le produit complet se compose de plusieurs applications utilisateur, de plus d’une douzaine de services et utilise environ 70 PBD)

OP – à moins que votre application soit exceptionnellement bien structurée (à l’origine écrite pour EA Server peut-être?), Il ne s’agira pas d’un port. Les choses fonctionnent trop différemment dans les environnements PB et .NET pour qu’un port ordinaire fonctionne correctement. Je ne saurais trop insister sur ce point – si vous utilisez réellement le modèle d’événement PB, un “port” sera probablement un échec.

Vous devez examiner le stream logique (interface utilisateur et processus interdépendants), le stream de contrôle (à qui appartient le processus ou les données actuellement ), l’access aux données (interface utilisateur, couche de données, ??) et les parties du modèle d’événement DW que vous utilisez. à partir du code. Si vous songez à ASP.NET (comme nous le sums), votre expérience d’interaction entre utilisateurs devra changer, ce qui se répercutera sur les autres considérations.

L’automatisation de la construction ne sera pas directement liée au code, nous allons utiliser PowerGen pour créer des versions PB cohérentes; MSBuild est très différent, de même que votre installation et votre configuration.

Je pense que quiconque envisage une telle application pour une application volumineuse serait assez fou de ne pas envisager sérieusement d’utiliser DataWindow.NET afin de ne pas perdre leur investissement dans les fichiers DW.

Les grandes entresockets du PHB pensent que Powerbuilder est un langage de jouets et que migrer vers un nouveau langage tel que C # est sortingvial et peut être effectué à moindre coût. En fait, la migration d’une application PB vers une autre langue coûtera au moins autant que le développement d’une application entièrement nouvelle sur la nouvelle langue. L’application résultante perdra généralement des fonctionnalités par rapport à l’originale et entraînera un mécontentement de l’utilisateur. J’ai vu un certain nombre de tentatives – toutes ont échoué à cause de la difficulté et des problèmes d’utilisateurs.

Si ce n’est pas cassé, ne le répare pas.

Oui, c’est faisable maintenant sans réécrire la période des composants de service.

PB 12.5>

Et ciblez les migrations et les intégrations de composants de service et d’interface graphique vers c #.

La stratégie de migration / intégration peut varier en fonction de la scope de votre projet, de son évolutivité, de ses ressources et de son calendrier.

Vous pouvez utiliser ces types de cible et de projet dans PowerBuilder .NET. Référez-vous à ce lien Sybase_PB .Net

• Application de fenêtre WPF Application de fenêtre WPF, proxy du client WCF ou proxy du client REST
• Assemblage PB Proxy client WCF, Proxy client REST ou Assemblage PB
• Proxy client .NET Assembly WCF, proxy du client REST ou .NET Assembly
• Service WCF Proxy client WCF, proxy client REST ou service WCF