Consigli per passare a un'architettura Delphi multilivello

Question

Abbiamo un'applicazione relativamente grande fortemente legata a Firebird (stored procedure, viste, ecc.). Ora stiamo ricevendo molte richieste per supportare database aggiuntivi e vorremmo anche spostare molte delle funzionalità dal client al server.

Ora sembra un buon momento per passare a un'architettura di livello 3 (4). Abbiamo già esaminato DataSnap 2009 e RemObjects SDK/DataAbstract. Entrambi sembrano fare il lavoro, ma ci sono dei vantaggi/svantaggi che dovremmo cercare? Ci sono altri quadri che potresti raccomandare?

Cheers, Paul

Answer 1

Nel processo di spostamento a un'applicazione multilivello si potrebbe considerare l'utilizzo di un protocollo di trasporto tra gli strati, che è il linguaggio/tecnologia indipendente (come webservices, (credo tha RemObjects sostiene che)).

Questo potrebbe rendere più semplice una reimplementazione di un livello più avanti (come se in un secondo momento dovessi creare un'altra versione dell'applicazione client in un browser/java/silverlight).

Answer 2

Posso consigliare l'utilizzo dei componenti middleware KBM da Components4Developers. C'è un po 'di una curva di apprendimento, ma sono molto flessibili e resistono bene in condizioni reali.

Comment from a user (http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm)

Answer 3

Modifica l'applicazione per Multi-Tires con il nuovo quadro (RM, DS, kbmMW, o che cosa mai), farà un sacco di cambiamenti nel nostro architettura applicativa, ho consigliato di andare con questo in futuro, ma è possibile ottenere il supporto per database multipli, con altri prodotti come

UniDac da DevArt (I migliori componenti per database con connessione diretta). AnyDac (dalla stessa società che offrono RemObjects. SqlDirect (Ha il supporto per 9 MajorDB e anche ODBC). ZeosDB (open source).

utilizzando uno dei componenti di cui sopra, vi darà supporto per la maggior parte dei database importanti, accanto a questo non ti faranno molte modifiche e in alcuni casi sostituirai solo i vecchi componenti del database con quelli nuovi e forse modificheresti alcune proprietà.

Tuttavia, il passaggio a multilivello non solo ti renderà Supporta solo più database, ma separerà la logica aziendale dal livello di presentazione, quindi puoi avere più livelli di presentazione per la tua applicazione come il web interfaccia o dispositivi intelligenti.

Ma il più importante nell'architettura Multi-Tiers, si avrà un sistema scalabile che cresce più di quello che il database che si sta utilizzando può gestire della connessione, oltre ad altri vantaggi, come l'utilizzo di altri linguaggi per scrivere applicazioni client.

Answer 4

Si può anche studiare Midware http://www.overbyte.be/frame_index.html

Answer 5

Per l'architettura multi-tier Consiglio anche di controllare middleware orientato ai messaggi.

Con middleware orientato ai messaggi, l'integrazione di applicazioni cross-language e cross-platform può essere implementata utilizzando il modello di comunicazione peer-to-peer o publish/subscribe. I sistemi di messaggistica sono liberamente accoppiati, asincroni e affidabili. Ad esempio, sono componenti principali nei server di applicazioni Java (tm) come JBoss.

per Firebird, di recente ho scritto un articolo del blog sulla sostituzione eventi Firebird database, i loro limiti e le modalità di sostituirli con soluzioni basate messaggio-mediatore (che sono disponibili come open source):

• Firebird Database Events and Message-oriented Middleware (part 1)
• Firebird Database Events and Message-oriented Middleware (part 2)

(disclaimer: sono uno sviluppatore di Delphi e free Pascal librerie client per i mediatori di messaggi open source).