Migrazione di un'applicazione Delphi 7 su .NET

Question

Qualche consiglio su come migrare un'applicazione aziendale Delphi 7 esistente su .NET 2.0 in Visual Studio 2005?

Visual Studio 2005 è già stato acquistato, la società vuole abbandonare gli strumenti Borland / Codegear.

L'applicazione è un eseguibile per server client singolo, che utilizza numerosi controlli dell'interfaccia utente di terze parti e report Crystal 10 per i report.

Esiste un'ampia logica di business diffusa tra i tipi di Delphi nell'interfaccia utente e molte procedure memorizzate di SQL Server 2000. Spostare gran parte della logica proc memorizzata in classi .NET è un altro obiettivo.

Per ridurre l'impatto sui clienti, sarebbe preferibile un approccio pezzo per pezzo piuttosto che una completa riscrittura / conversione, se possibile. Grazie in anticipo.

[Aggiornamento] Qualcuno ha avuto qualche esperienza, buona, cattiva o brutta, usando Managed VCL per questo tipo di scenario?

Answer 1

Ho lavorato in un'azienda che stava migrando da Delfi a WPF / .Net verso il 2007. Abbiamo provato un approccio pezzo per pezzo. È stato doloroso. Ci siamo sempre imbattuti in bug sottili nell'interoperabilità. Chiamare da Delphi a WPF o Winforms e viceversa è doloroso. Se i vari controlli dell'interfaccia utente e le finestre della tua applicazione si chiamano molto l'un l'altro, penso che sperimenterai notevoli problemi di crescita.

Se puoi permetterti di fare l'intera conversione in una sola volta, ci proverei. In caso contrario, dividere le parti dell'app che sono indipendenti o che hanno il minimo di interazioni con il resto dell'app.

Suggerirei anche di entrare in .Net 2008. Perché scegli una tecnologia che ha quasi 4 anni (VS 2005)? Penso che sia una pessima decisione commerciale scegliere di passare a .Net 2.0 quando .Net 3.5 è molto stabile. L'unico motivo valido che avrei mai presentato al management per .Net 2.0 sarebbe supportare Windows 2000. Hai ancora clienti su Win2k? Avrai ancora clienti su Win2k al termine della conversione? Hai clienti che non riesci a passare a XP o Vista? .Net 3.0 e 3.5 non sono supportati in Win2k. Questo è l'unico aspetto negativo che mi viene in mente.

.Net 3.5 e C # 2008 offrono vantaggi significativi per la tua azienda. Sono disponibili numerose funzionalità linguistiche che accelerano i tempi di sviluppo rispetto a C # 2.0. Hai WPF, che è di gran lunga superiore a Winforms. Direi che puoi sviluppare le stesse finestre grigio-batteleship che otterrai in Winforms con WPF, svilupparle più velocemente e quando vuoi un po 'di piacere utilizzerai una tecnologia che può facilmente fornirla. Se stai imparando una nuova piattaforma per questa conversione, perché non investire nell'apprendimento delle nuove cose?

Inoltre, ti prego, dimmi che non hai effettivamente acquistato VS 2005. Puoi acquistare un MSDN Universal per circa lo stesso costo e ottieni tutti i prodotti relativi allo sviluppo prodotti da Microsoft. Compralo da una terza parte e otterrai uno sconto eccezionale.

Scusami se sono venuto fuori negativo. Cordiali saluti, buona fortuna per la migrazione. Ho solo dei flashback quando penso di dover rinunciare a tutti i bonus di .Net 3.5.

Answer 2

Sembra una davvero una pessima idea per me.

Esistono vantaggi tecnologici per il tuo prodotto in .NET o è principalmente una decisione politica diventare un negozio Microsoft? Per client-server, Delphi è piuttosto difficile da battere. Ho usato VS2005 / 8 ed è davvero e sinceramente e sinceramente non buono come Delphi per lo sviluppo di Win32. Ma se hai intenzione di migrare sul Web lungo la strada, allora VS ha dei vantaggi definiti.

Se gli uomini d'affari testardi semplicemente rifiutano di usare più Delphi, allora KiwiBastard ha ragione, IMO. Convertire prima in Delphi.NET, quindi migrare da lì a VS2005. O 2010, dal momento che questa è una linea temporale più realistica :)

Answer 3

In precedenza ho lavorato in un'azienda che voleva convertire da Delphi a C # .NET perché .NET è tutto bello e brillante . Hanno portato altri sviluppatori che hanno avuto molta esperienza in C # e alla fine ci sono voluti 3 volte gli sviluppatori il doppio del tempo necessario per trasferire l'applicazione su C #, quindi lo ha scritto per la prima volta in Delphi per un ROI aggiuntivo molto limitato (alcuni nuove funzionalità sono state aggiunte nel processo). Inoltre, i clienti non erano soddisfatti delle prestazioni dell'applicazione o dell'interfaccia utente.

Case study after case study mostra che riscrivere è una cattiva idea . (Suggerimento per il cappello a kogus )

Se devi passare a .NET (sì, lo so, non hai preso la decisione, qualcuno con meno informazioni ), suggerirei di usare Delphi per .NET o RemObjects Oxygene . Quest'ultimo è un plug-in di Visual Studio. Ma anche marc hofman, Chief Software Architect di RemObjects Oxygene ha affermato che è una cattiva idea eseguire la migrazione di un'applicazione perfettamente funzionante su .NET "solo perché."

Se puoi aspettare Delphi Prism, che è anche un componente aggiuntivo di Visual Studio e dovrebbe uscire entro la fine dell'anno.

Answer 4

Una conversione frammentaria significherebbe cambiare il codice Delphi nativo per usare COM in modo che il lato .NET possa coesistere con Delphi (o possibilmente usare qualche altra tecnologia - difficile da dire)

Se possibile, potrebbe essere più semplice convertire prima l'app in Delphi.NET, quindi almeno i bit .NET saranno in grado di comunicare un po 'più facilmente.

Solo un pensiero.

Answer 5

Allontanandosi dagli strumenti CodeGear / Borland elimina sostanzialmente qualsiasi soluzione basata su Delphi .NET e una riscrittura totale della tua applicazione.

Spero che la mia risposta di seguito aiuti nelle tue decisioni.

Per esperienza (dopo aver riscritto un'applicazione Delphi con un team di persone) si riduce a una delle due seguenti opzioni.

Ma prima un avvertimento: dovrai fare almeno lo sforzo di sviluppo totale necessario per scrivere la tua attuale applicazione Delphi.

Nel nostro caso, questo sforzo è stato garantito in quanto la vecchia applicazione Delphi (che in realtà era Kylix) aveva una fine vita a causa di vari motivi. La nostra riscrittura consisteva in due parti: riscrivere con funzionalità extra limitata seguita da molte funzionalità extra (il design della prima parte ha già preso in considerazione la seconda parte).

Torna alle tue scelte:

1- una riscrittura totale in C # o VB.NET in Visual Studio

2- un riutilizzo parziale del codice del livello aziendale di Delphi esistente utilizzando Oxygene di RemObjecs (un plug-in Visual Studio con una sintassi molto simile alla sintassi Delphi). CodeGear offrirà Prism presto (probabilmente prima della fine del 2008), che si integrerà anche in Visual Studio.

Poiché l'accesso ai dati .NET e l'interfaccia utente sono totalmente diversi da Delphi, dovrai farlo da zero (sia per gli scenari 1 che 2). Visual Studio 2008 offre molti vantaggi qui rispetto a Visual Studio 2005.

Non è possibile eseguire questa migrazione gradualmente, poiché qui si esegue una modifica completa della piattaforma, si tratta di un approccio tutto o niente.

Entrambi gli scenari impiegheranno molto tempo (anche se hai l'esperienza Delphi, per abituarti al mondo .NET ci vorrà del tempo).

Visual Studio può interagire con Crystal Reports e funziona bene con SQL Server.

Dal momento che Visual Studio 2008 offre molti vantaggi (non solo .NET 3.5, ma anche per quanto riguarda la produttività), è meglio andare con quello. Per quanto riguarda l'interfaccia utente, è necessario effettuare una scelta bilanciata tra WinForms (aka Windows Forms) e Windows Presentation Foundation (aka WPF).

Se si tratta di una riscrittura da 1 a 1, potresti voler rimanere con WinForms perché è familiare a quello che hai. Probabilmente dovrai utilizzare alcuni componenti di terze parti per avviare l'interfaccia utente; DevExpress è una buona scelta qui in quanto hanno componenti simili in Delphi e Visual Studio.

Ma se vuoi andare per un futuro piacere per gli occhi, allora potresti prendere in considerazione WPF. Preparati per una curva di apprendimento più ripida qui rispetto a WinForms in quanto è molto diverso da quello a cui sei abituato.

Se decidi di rimanere con Delphi, potresti voler esaminare VCL per il Web (alias IntraWeb) e Delphi 2009 (molto è cambiato nel mondo di Delphi da quando Delphi 7 è stato annunciato 6 anni fa).

Buona fortuna a fare le tue scelte!

- Jeroen

Answer 6

Suggerirei di guardare Hydra da RemObjects. Fondamentalmente rap l'interfaccia COM per te e fornisce un modello di osservatore per l'interfaccia tra l'applicazione Delphi e .Net. Puoi avere moduli .Net visualizzati sui pannelli all'interno della tua app Delphi. Ciò fornisce un percorso di migrazione piacevole in cui si sostituisce il codice Delphi bit per bit durante la migrazione della funzionalità a .Net.

Answer 7

Per me la domanda sarebbe: quale lingua useresti? Spero C # e non VB.Net. (Con tutte le imbarazzanti politiche in questo caso, questo non è chiaro in alcun modo.)

Il prossimo che probabilmente sentirai è che ci sono convertitori là fuori che ti aiuteranno a farlo. Abbiamo appena passato una valutazione di tali convertitori (da Delphi 7 a C #) ed eravamo molto! deluso.

Posso suggerire un compromesso? Che ne dici di Delphi Prism? È Delphi in VS2008. Certo, hai ancora Delphi e quindi Codegear, ma hai anche VS (come la tua azienda si aspetta).

Answer 8

C'è stato un rapporto scientifico di una trasformazione riuscita di un progetto Delphi da 1,5 milioni di linee in C # di John Brant, Don Roberts e altri Ha scritto un parser Delphi, un generatore C # e molte regole di trasformazione sull'AST. Estendere gradualmente il set di regole, fare una build giornaliera, un sacco di test unitari e qualche riscrittura di parti difficili di Delphi gli hanno permesso con un team di 4, tra cui alcuni degli sviluppatori originali, con profondo Delphi & amp; Conoscenza C #, per migrare il software in 18 mesi. John Brant & amp; Don Roberts essendo gli sviluppatori originali del browser di refactoring e del kit di costruzione del compilatore SmaCC, è improbabile che tu possa andare così veloce.

Anche se si è trattato di un investimento significativo, non è in alcun modo "uguale alle dimensioni dello sviluppo originale". Gli autori notano che una riscrittura semplice, senza strumenti o con uno strumento a colpo singolo, come notato da Jeroen, è molto probabile che ciò comporti questo, specialmente se si prendono in considerazione nuovi requisiti.

Gli autori hanno effettuato refactoring su larga scala rimanendo sulla stessa piattaforma per un progetto diverso, sostituendo completamente l'infrastruttura di persistenza. Questo potrebbe essere rilevante per i progetti più vecchi (BDE?).

Answer 9

Solo tu puoi davvero decidere se è possibile un approccio pezzo per pezzo. Ad esempio, l'applicazione può essere facilmente suddivisa o tutti i moduli sono accoppiati in modo troppo forte con tutta la logica aziendale. Tecnicamente è possibile, ma tutto dipende da come è strutturata la base di codice.