Un piano progressivo da vb6 a .net, suono?

3

Stiamo per avviare un nuovo progetto utilizzando un DB SQL esistente, ma questo progetto avrà bisogno di riutilizzare un certo numero di funzioni principali da un'app vb6 esistente che utilizza lo stesso database.

L'approccio che vorrei provare:

Avere l'applicazione vb6 esistente come punto di ingresso, ma chiamare immediatamente una classe .net per presentare la schermata principale e il menu. Se l'utente deve utilizzare una funzione / modulo che si trova in vb6, quindi genera un evento su vb6 per caricare quel modulo e nasconde il suo lato .net fino a quando non viene completato.

L'alternativa:

Di fronte a quanto sopra, crea un .net exe per essere il punto di ingresso e chiama una vb6 dll ogni volta che ho bisogno di una funzione / modulo vb6.

A causa dell'inizializzazione che si verifica nell'app vb6 che rende utilizzabili varie funzionalità, sarebbe molto meno doloroso per me provare il primo approccio. Inoltre, c'è una funzionalità strettamente accoppiata ai moduli nell'app vb6 ed è vitale per l'applicazione, ma non potrò immediatamente portarla su .net nella prima fase.

Mi rendo conto che questo non è l'approccio ideale, ma sfortunatamente ci sono preoccupazioni del mondo reale che rendono l'approccio idealistico vicino (se non del tutto) impossibile.

Quindi la mia domanda è: ci sono delle insidie specifiche di cui dovrei essere a conoscenza nel fare questo?

    
posta Brandon Moore 22.02.2012 - 19:34
fonte

1 risposta

4

Direi che l'approccio più praticabile è utilizzare il metodo Strangler Vine. Martin Fowler fa un ottimo lavoro all'indirizzo descrivendo l'approccio (ho trovato anche un article su docstoc che entra più nel dettaglio.

Inoltre è difficile consigliare quale approccio potrebbe funzionare al meglio per te, ma ho sempre trovato che ospitare moduli VB in .NET è più facile del contrario.

    
risposta data 22.02.2012 - 22:23
fonte

Leggi altre domande sui tag