Conversione del nostro software Windows sul Web [chiuso]

The project consists of 200+ database tables, 100+ reports, 300+ Views, 100+ Dialog boxes and 200 or so Selection Lists.

Poco importa. Ricorda, tutto ciò era un cattivo, vecchio design. Questo è parte del motivo per cui lo hai sostituito.

Even simple screens (Entering a stock location) seems overly complex.

Due cose:

• Ripensa i tuoi casi d'uso. Molte applicazioni legacy hanno una cattiva progettazione, un cattivo flusso di lavoro e schermi occupati pieni di troppo del tipo sbagliato di dettagli.

• Ripensa il tuo set di strumenti. Lo stato dell'arte, (ASP.Net, RoR, Django + Python) fornisce le pagine amministrative ("CRUD") quasi gratis. Programmazione zero.

how I can move from my current VB style programming language to one that allows similar functionality on the web?

No. Non riesci a trovare la funzionalità "simile".

Devi cambiare.

Has anyone got any ideas how I go about working out how many man hours it's going to take to convert this sort of project to a new language on the web?

Passaggio 1. Rompere l'intero contenuto in casi d'uso, incentrati sugli attori e le loro esigenze ("User Story")

Passaggio 2. Approssimativamente - solo a livello di riepilogo - definisci quei casi d'uso e il valore relativo che è stato creato.

Passaggio 3. Per i casi di utilizzo di alto valore solo progettare un modello di dati corretto e iniziare a costruire con strumenti all'avanguardia.

Passaggio 4. Rilasciare qualcosa utilizzabile entro pochi mesi. Dovrai "collegare" i dati dal vecchio sistema al nuovo sistema per farlo funzionare. Mantieni il bridge semplice, verrà eliminato.

Passaggio 5. Iterate quanto sopra cercando di ottenere un ciclo di rilascio più breve. Rilascia meno cose più spesso.

A un certo punto, avrai a disposizione un sacco di funzionalità legacy non interessanti che non hai convertito e che non ti servono. Avrai programmi bridge che non creano più valore.

What Web Framework options are available, and how do I decide between going with something like Rails vs going with something like ASP.Net?

Ci sono milioni di framework. Non c'è una guida per sceglierne uno.

Perché? Sono tutti davvero bravi.

We've a tonne of code wired to OnClick and OnChange events. (I know this is bad). What strategies can I take with regard to converting this to the web?

Ripensa i tuoi casi d'uso dalla fondazione.

Chi sono gli attori? Cosa fanno che crea valore? Come vogliono interagire con un sistema per creare quel valore?

Il tuo sistema legacy ha molti dati storici utilizzabili. Nient'altro ha valore. Quindi sentiti libero di scartare i flussi di lavoro legacy e i passaggi di elaborazione.

Relax

Ecco cosa devi fare "Alto livello":

1) Documenta il sistema corrente

• Che cosa sono le schermate, i report e i processi nel sistema attuale?
• Che cosa fanno?
• Quali sono usati?
• Mappa di un ERD (diagramma base dati)

2) Definire l'ambito del nuovo progetto.

• Tutto ciò che sta passando al sistema attuale? (Vedi i tuoi documenti al punto # 1)
• Quali funzionalità saranno aggiunte? Cosa verrà rimosso? Cosa cambierà? Cosa DEVE essere fatto prima di andare in diretta? Puoi implementare un approccio graduale?

3) Metti insieme un progetto di alto livello.

• Crea alcuni prototipi di schermate
• Layout dell'interfaccia utente (approssimativamente)
• Decidi su una tecnologia
• Esegui alcune prove della codifica del concetto (questo ti farà sapere se la progettazione funzionerà e ti aiuterà a stimare la tua linea del tempo)

4) Unire un piano di progetto. Sequenza temporale i bilanci Risorse necessarie Esegui il tuo piano.

Se non fosse per questa affermazione:

Is there any language that allows me access to the database without having to subclass everything through IEnumerable and various weird Typecasting things.

Ti consiglierei di guardare Silverlight con i servizi RIA.

L'architettura consente di costruire un'applicazione che si trova all'interno di un browser web. Offre agli utenti i vantaggi di lavorare sul Web - nulla da installare (bloccare il client Silverlight), la possibilità di aggiornare l'applicazione centralmente, ecc.) Dando allo sviluppatore più controllo sull'aspetto e l'aspetto dell'applicazione rispetto a un'applicazione web tradizionale.

Prima ancora di iniziare a fare questo:

"Stiamo valutando la conversione di un pacchetto software da Windows al browser: è un sistema di back office costituito da libri mastri, controllo delle scorte, elaborazione degli ordini, ecc. ed è scritto in un linguaggio legacy (Dataflex)."

Chiedi, e hai una buona risposta alla semplice domanda: perché vuoi farlo?

È bello avere? È essenziale? È così che puoi guadagnare? È perché qualcuno ha pensato che sarebbe stata un'idea chiara?

Stai per intraprendere un enorme compito di sviluppo del software; come faranno queste cose, introdurre nuovi difetti e causare un cambiamento dei processi.

Quindi alcune domande supplementari:

Sei, o è la tua organizzazione, preparata per il costo (in termini di sforzo di sviluppo, personale deviato, correzione di difetti, interruzione, ecc.)?

Sei pronto per il parallelo? (Se non lo si deve tagliare in un determinato momento e in quel momento il NUOVO deve funzionare. Funziona davvero. Non eseguire il debug dopo il cutover.)

Devi eseguire la migrazione dei dati? (Su un magazzino / sistema di inventario, scommetto che lo farai, altrimenti ci sarà il reinserimento di dati esistenti.)

Puoi semplicemente comprare qualcosa? O affittare? Ci sono tali sistemi disponibili ora come servizio, basta pagare un canone mensile.

Le mie scuse. Ci sono stato, fatto.

We've a tonne of code wired to OnClick and OnChange events. (I know this is bad). What strategies can I take with regard to converting this to the web?

• refactoring . Prima di tutto, e prima ancora di iniziare a programmare qualsiasi cosa relativa al web. Riforma l'inferno della soluzione esistente finché non ottieni una base di codice in cui l'interfaccia utente e la logica sono separate il più possibile. Questo non sarà sempre facile con il codice legacy, ma l'investimento sarà ampiamente ripagato non appena inizi lo sviluppo web.

• Resisti all'idea (molto allettante) di fare riferimento ai controlli di Windows nella logica. L'obiettivo è mantenere la logica completamente indipendente da qualsiasi interfaccia utente , anche se ciò complica un po 'le cose. Potresti dare un'occhiata a concetti come MVVM, MVP, ecc. Per avere un'idea di come strutturare le cose.

• L'interfaccia utente specifica della piattaforma dovrebbe essere trasformata in qualcosa che non ha alcuna logica. Tuttavia, anche se DRY suona bene in teoria, non regge con le applicazioni distribuite. Nella vita reale scoprirai che dovrai duplicare alcune parti della logica per l'interfaccia utente del cliente. L'esecuzione di un round trip del server per ogni singolo evento di controllo dell'interfaccia utente porta solo a un'interfaccia utente terribilmente lenta, a causa di latenze richieste inevitabili. Inoltre, produce molto traffico non necessario.

• Per ragioni di sicurezza , qualsiasi controllo relativo alla sicurezza effettuato sull'interfaccia utente del client deve sempre essere eseguito sul lato server, prima di elaborare la richiesta. Le richieste possono essere contraffatte e manomesse e non tutti i client che parlano di HTTP al tuo server sono in realtà un browser web.

Buona fortuna!