2010-06-29 11 views
6

Scrivo software da diversi decenni e in questi giorni tutto è web.
Prima del web avevamo app Client Server che erano fondamentalmente applicazioni client spesse che parlavano direttamente al database. Avevano alcuni svantaggi, come l'implementazione era ingombrante, non scalabile perché DB gestiva tutto il traffico. Ovviamente allora la distribuzione delle app era limitata ad essere su un desktop su una rete aziendale. I vantaggi di queste app erano che avevano meno strati e si sviluppavano rapidamente.Qualcuno ancora usa Client Server Architecture

Ci sono momenti in cui i requisiti richiedono un'app dietro un firewall con un database dedicato e una quantità relativamente piccola di client. Suggerisco (a volte su StackOverflow) la vecchia architettura di tipo Client/Server e tutti mi guardano come se avessi 3 gambe e 6 braccia.

Con tecnologie moderne che consentono l'implementazione automatica di app e gli strumenti che abbiamo oggi. C'è una ragione per cui questa tecnologia non è praticabile? È che la nuova generazione di sviluppatori conosce solo le cose del web?

+1

Cosa, mai sentito parlare delle applicazioni Access? – Earlz

+1

Ehi, ragazzi! Vattene dal mio prato! – Stephen

+0

In questi giorni soffoco ogni volta che qualcuno dice che i browser sono thin client ... non hanno fatto capolino nella lista dei componenti aggiuntivi nel mio FF ... –

risposta

6

Sono sicuro che i client spesso sono ancora in fase di sviluppo, anche oggi.

Detto questo, la scelta di un'architettura web-based non si tratta di "nuova generazione di sviluppatori" solo conoscendo roba web, è possibile prendere un sacco di vantaggi se si può fare web-based dell'applicazione:

  1. La distribuzione è semplice. Anche con cose come ClickOnce, aggiornamenti automatici, ecc, niente di meglio semplicemente aggiornando la pagina per ottenere l'ultima versione
  2. Puoi usare qualcosa come Silverlight per ottenere il 99% dei vantaggi di un'applicazione desktop (in termini di capacità di esecuzione codice sul client)
  3. Le applicazioni Web possono essere rese disponibili in remoto molto più facilmente delle applicazioni desktop (molte aziende hanno lavoratori remoti in questi giorni, l'impostazione di una VPN è un problema se tutto ciò che si vuole fare è accedere al libro paga (o qualunque))

Ma alla fine della giornata, è tutto lo strumento giusto per il lavoro. Le applicazioni Web non aiutano quando si desidera scrivere plugin per Office (Word, Outlook, ecc.), Non aiutano se si deve controllare l'hardware personalizzato (terminali POS, ecc. - sebbene si possa scrivere nel server in alcuni casi ...), e probabilmente anche qualche altro caso.

7

Mi vengono in mente almeno due grandi-ish mercati in cui client-server è ancora grande:

  • giochi online e mondi virtuali, come Battlefield o Second Life. Di solito è necessario un client spesso più una connessione a un server condiviso.
  • Software scientifico personalizzato. Un software tecnico o scientifico complesso, specialmente se ha bisogno di un'interfaccia grafica interattiva che faccia manipolazione diretta, a volte viene anche scritto in questo modo.
1

Abbiamo alcune app Flex che comunicano con servizi Web basati su XML che sono molto vicini alle app di Client Server di vecchia scuola. Ma piuttosto che usare SQL, parlano un linguaggio XML personalizzato e rendono le risposte SOAP.

+2

Quindi è necessario programmare, mantenere e amministrare un livello intermedio. XML è ingombrante. È uno strumento per molte app, ma sto cercando di convincere le persone che ci siamo allontanati dalla semplicità, dove a volte una soluzione più semplice è ancora la migliore. Scrivo anche app GWT e app web, quindi comprendo i meccanismi. –

1

Attualmente sviluppiamo e distribuiamo numerose applicazioni client/server ogni anno. Lo sviluppo è semplice e automatizzato. Non siamo limitati alle tecnologie di database che siamo in grado di implementare.Le implementazioni client/server sono più veloci per calcoli, aggiornamenti di moduli e rapporti. Le applicazioni basate su Web/cloud sono meno reattive di un'applicazione in esecuzione su una stazione client (thick client).

Ciò è dovuto alla distribuzione del carico della CPU. Mentre un'applicazione lato server richiede che il server esegua tutti i calcoli, il lato client può eseguirlo sul computer locale. Come ogni sistema diventa più complesso, i momenti che un utente deve attendere per i risultati aumenta. Questi momenti di tempo impiegato sono più costosi in quanto coinvolgono più dipendenti retribuiti. Questi momenti si sommano all'interno di un'organizzazione come un gran numero di "ore uomo" in un anno.

I problemi con gli aggiornamenti sono risolti all'interno del nostro set di strumenti di sviluppo. Proprio come quando puoi aprire il tuo browser preferito, ti accorgi che la versione che stai utilizzando non è la più recente, ma incorporiamo lo stesso processo all'interno delle nostre applicazioni client/server. In realtà non diamo loro una scelta da aggiornare. Poiché gli aggiornamenti possono, molte volte, richiedere modifiche al database, forziamo l'aggiornamento a verificarsi prima che l'utente possa eseguire il software.

Per migliorare la visibilità delle informazioni contenute nei nostri sistemi client/server personalizzati, offriamo siti Web personalizzati sviluppati con applicazioni specifiche come l'invio sul campo o l'integrazione del forum di assistenza clienti nelle applicazioni client/server desktop. Dal mio punto di vista vedo una completa integrazione del server client e delle applicazioni web reattive che assumono una posizione migliore negli anni a venire.