Spostamento di una vecchia applicazione desktop su una piattaforma solida [chiusa]

Mi dispiace, ma questa è follia. Riscrivere un'applicazione funzionante in una lingua diversa perché a qualcuno non piace lo stile dei conduttori di accesso ai dati ?! Sono spese, sforzi, interruzioni e rischi inutili. Dov'è il ROI? Qual è il time-to-value? Se la domanda descrive il ragionamento completo, le metriche aziendali go / no-go standard non possono supportare il rip-and-replace.

Questo non perché non sono d'accordo. Le connessioni dirette al database presentano alcuni aspetti negativi, come la scalabilità limitata e la probabile violazione dell'approccio di sicurezza con privilegi minimi. Bloccano l'interpretazione dei dati nelle app client, rendendo le applicazioni multi-piattaforma, le code a versione lunga e le attività combinate come l'analisi dei dati più impegnativa. E Delphi 7 sta diventando un po 'lungo nel dente. Ecc. Ecc.

Se eri una società di software commerciale, era necessario aumentare notevolmente il numero di utenti simultanei, necessario per operare con utenti meno fidati o su reti meno sicure, o se avevi bisogno di una connessione specifica che impediva o precludeva le connessioni dirette al database , Sarei il primo a concordare con "aggiorna la tua architettura" o "modernizza i tuoi strumenti". Ma almeno dalla tua domanda, quelli non sembrano essere il caso. Sei una società di medie dimensioni; il software sembra fare il suo lavoro; e non vi è una chiara motivazione per una ricostruzione pulita delle ardesia o per una maggiore rotazione del terreno. Ciò rende questo un aggiornamento importante per conformarsi alle preferenze architettoniche di qualcuno. Ciò viola primum non nocere ("primo, non nuocere") a beneficio discutibile.

Questo è aggravato dalla probabilità che non ci siano buone suite di test per confermare che una nuova build "pezzo di carta pulito" funzioni correttamente. (Non sentitevi troppo male a questo proposito - la maggior parte dei negozi non fa per le loro app interne.) E se si tratta di software di contabilità, ottenere dati errati può avere conseguenze commerciali estremamente negative. Tutto questo urla "questo finirà male!" - o almeno, "alla fine sarai infelice che tu abbia deciso di ricostruire qualcosa che ha già funzionato per ragioni traballanti, piuttosto che lavorare su qualcosa che potrebbe davvero aiutare l'azienda." Ho visto troppi progetti di lavagna pulita finire in questo modo.

Il roto-tilling principale o l'inizio-fresco possono funzionare - ma devi avere un supporto sostanziale, la gestione e gli utenti che lo accettano impiegheranno un po 'di tempo e introdurranno interruzioni lungo il percorso e, cosa più importante, una solida ragione per farlo modo.

Invece, ti suggerisco di esaminare quali percorsi di aggiornamento incrementali potresti avere da Delphi 7 , e sviluppare un piano più incrementale e una motivazione più basata sui benefici per apportare modifiche sostanziali.

Non è chiaro se stai dicendo che il problema del tuo CIO con il tuo progetto è la connessione DB persistente, o il fatto che usi utenti dell'applicazione mappati agli utenti di DB. Né è necessariamente un'architettura BAD, a seconda dei requisiti. Ci sono molte applicazioni che fanno la stessa cosa, anche roba di fascia alta che gira su Oracle Enterprise.

E, anche se elimini la connessione diretta persistente, un amministratore competente (molto meno hacker) che esegue l'app localmente, con o senza accesso al server DB, sarà in grado di connettersi direttamente al database se lavora abbastanza duramente . Perchè questo è un problema? Certo, non vuoi che sia pubblico, ma le app interne possono essere gestite con le regole del firewall o con l'app co-residente + db sullo stesso server. Tradizionalmente, se incorporiamo un motore di database in un'app, non cambiamo la porta. La sicurezza non può essere basata sull'oscurità. Assicurati che l'app sia co-residente, quindi non c'è alcuna connessione di rete DB eccetto localhost, o assicurati che stia usando una sessione crittografata, che rimuova il problema dello snooping della rete, ma lasci possibilità di hacking locale. Al di fuori di quello, qual è il problema?

Non sei in grado di dedicare un'istanza di database all'app? Forse vuole che la tua app coesista su un'istanza di SQL Server con altre app. Se è così, posso capire il requisito, ed è una buona cosa. La scelta di mappare utenti a veri utenti di DB non è stata una grande scelta, ma non è la fine del mondo, è più un progetto di vecchia scuola che funziona, ma limita le opzioni (richiede un database dedicato). Ora che funziona, devi pesare i costi. Forse il tuo CIO ha già.

Proseguendo, il modello più comune è un server locale (LAN locale) per l'applicazione desktop installata localmente. In caso contrario, si passa a un modello Web SaaS completo o si utilizza la sincronizzazione disconnessa. Non è un server Web OLTP quindi non capisco il problema con le sessioni persistenti. Se è bloccato su questo punto, c'è ancora del buono nel rearchitecting it ... ecco alcune opzioni, con vantaggi.

È possibile portare un progetto SQL connesso a un progetto SOA disconnesso creando un "agente" di servizio (servizi WCF che servono le chiamate dati). È necessario associare tutte le query alle chiamate di servizio, implementarle in un livello di servizio, quindi distribuire tale livello di servizio come front-end del database. Puoi comunque utilizzare le griglie dei dati fat client come desideri, ma i dati passano tramite WCF o servizi dati dall'app al broker, dal broker al DB e, se hai bisogno di essere fantasioso, puoi implementare IQueryable e la tua origine dati personalizzata per consentire criteri di query arbitrari. Non sto dicendo che sia indolore ed economico per la transizione, ma funziona. Il vantaggio è che puoi spostare il tuo server dati ovunque su Internet (cloud) e la tua app per il grasso può ancora funzionare su HTTP / HTTPS. C # / .NET è perfetto per questo. L'interoperabilità dei servizi è molto ricca.

Se il tuo DB non è locale su una LAN / WAN e le prestazioni / la latenza sono un problema, ci sono anche altre opzioni con cui ho avuto successo, come l'implementazione di un database SQLAnywhere locale, la replica dello schema del master DB e utilizzare Mobilink per la sincronizzazione con il database consolidato. Esistono molti prodotti commerciali con SQLAnywhere incorporato o DB Ultalite o DB SQLLite che utilizzano questa architettura. (Odio dare via i trucchi del mio mestiere ma ...)