Quali sono i vantaggi dell'utilizzo di DB Aware Controls anziché di DB Aware Control in Delphi

Question

Vorrei persuadere un amico a me che l'utilizzo di Componenti database (DB Aware Controls) in Delphi è di gran lunga l'opzione migliore quando si sviluppano applicazioni di database.

Questo dibattito è iniziato con lui molti anni fa: ancora oggi è convinto che l'utilizzo di semplici controlli come TEdit, TStringGrid ecc., Con una serie di metodi getter e setter per popolarli, sia la soluzione migliore sia in termini di flessibilità e manutenibilità dell'intero progetto.

Per me questo suono contro-intuitivo almeno.

Penso che usare DB Aware Controls, come TDBEdit, TDBGrid ecc. Sia la cosa giusta da fare quando si sviluppano applicazioni di database.

Quindi: per favore aiutami a convincerlo con buoni consigli sull'utilizzo di DB Aware Controls!

Grazie in anticipo a tutti coloro che pubblicheranno almeno il proprio consiglio, qualunque cosa sarà a favore dell'una o dell'altra soluzione.

- Fabio Vitale

Answer 1

DB-Aware vs non DB-Aware è una specie di discussione obsoleta. I controlli DB-Aware hanno un collegamento automatico dei dati, il che significa che si auto-compilano automaticamente con i dati, cambiano il rilevamento e scrivono ai membri del datasource delimitati; nei controlli non-dbaware, sta a te fare quelle attività. Ciò può portare anche a un codice disordinato o a quadri troppo ingegnerizzati solo per fare il databinding. Entrambi gli scenari sono cattivi.

Il tipo di origine dati e la qualità del controllo individuale determinano le prestazioni. Ho visto molto codice per databind TStringGrid semplicemente per evitare TDBGrid a causa del purismo (quando TDbGrid andava bene) - solo uno eccessivamente assurdo perdita di tempo.

È diventato una discussione obsoleta quando TClientDataset è diventato il set di dati de-facto per le applicazioni disconnesse: è possibile estrarre dati, disconnettersi, lavorare sui dati, connettersi nuovamente e applicare le modifiche. Poiché i controlli CDS + DbAware eseguiranno il 99% dell'interfaccia, i controlli non sensibili ai dati verranno utilizzati per l'1% successivo (per alcune interfacce complesse).

Non ho ancora XE2 per vedere se LiveBindings esegue correttamente il databinding OO - in caso affermativo, ora tutti i controlli possono db-aware se necessario.

EDIT: nella risposta di da-soft, lui (lei?) Sostiene che DbAware controlla implementa pattern MVC e LachlanG non è d'accordo sul fatto che, anche se lo fa, il codice stesso non è MVC. Darò i miei $ 0,02 centesimi qui ;-)

Penso che l'uso di una relazione 1: 1 in DataModule ed Entità (come in ERD) - o DataModule e un Form - è possibile ottenere un'applicazione dove le responsabilità sono separati:

• forma DFM -> layout e in fase di progettazione l'associazione dati (hanno solo Datasources)
• forma *.pas -> controlla interfaccia e chiede modulo dati per i dati (agisce come un controllore)
• dati del modulo -> metodi per rispondere forme richieste di reperimento dei dati e dati aggiornamenti

ho normalmente un modulo dati divisi per connessione al database che è passata attraverso le proprietà di moduli/entità.

Answer 2

DB-aware controlli pro:

1. Il lavoro per caricare i dati a un controllo e salvare i dati in un set di dati viene eseguita da VCL. Hai meno codice - davvero RAD.
2. I controlli DB-aware + TDataSource + TDataSet implementa il pattern MVC. Ciò aiuta a separare la GUI e il codice di accesso ai dati.
3. Il codice che convalida, riformula, esegue altri processi di elaborazione dei dati verrà chiamato in momenti ben definiti utilizzando i gestori di eventi. Ciò aiuta a centralizzare tale codice ed evitare confusioni con i luoghi in cui dovrebbe essere collocato. Ed evitare le confusioni con i momenti in cui chiamarlo.

Contro:

1. Questo non è un approccio universale. Non è possibile associare un controllo compatibile con DB a un'origine dati diversa da TDataSet. Questo problema è stato risolto introducendo Live Data Binding in Delphi XE2.
2. La programmazione guidata dagli eventi potrebbe confondere alcuni sviluppatori. E richiede la conoscenza di TDataSource, TDataSet, TField eventi e architettura, e portare a polemiche con i professionisti (3). Il codice guidato da un evento errato può essere un incubo.

Answer 3

Entrambi i componenti DB-aware e non DB-aware presentano vantaggi e svantaggi, a seconda del tipo di applicazione che si sta sviluppando.

Per applicazioni di piccole e medie dimensioni, è consigliabile utilizzare componenti compatibili con DB, a meno che non vi siano requisiti o condizioni specifici in base al quale tali applicazioni sono operative. Ad esempio, una semplice applicazione di inserimento dati sarebbe più facile da sviluppare e mantenere con i componenti compatibili con DB. Anche le applicazioni di scala medio-grande, se correttamente progettate e implementate, avranno buone prestazioni con componenti compatibili con DB.

Tuttavia, quando si sviluppano applicazioni modulari, in particolare sistemi a più livelli, i componenti compatibili con DB possono avere un impatto negativo sulle prestazioni dell'applicazione e sulla manutenibilità. Ciò è particolarmente evidente con le applicazioni che accedono ai dati su Internet.Il motivo principale di ciò è dovuto al fatto che i componenti compatibili con DB richiedono una connessione costante al database, che può aumentare significativamente il traffico di rete.

L'utilizzo di componenti non sensibili al DB può essere più complesso in quanto richiede una migliore comprensione dei meccanismi sottostanti, ma in ambienti multi-utente e distribuiti su più livelli è scalabile molto meglio di qualsiasi altra cosa. Inoltre, puoi (e dovresti) separare il livello di accesso ai dati dal livello di presentazione (UI), che in seguito ti consentirà di apportare modifiche a un sottosistema (modulo, livello) senza dover modificare altro.

Oggi i dati possono essere ovunque e la maggior parte delle volte non vengono memorizzati su computer o reti locali. L'utilizzo di componenti compatibili con DB per accedere a tali dati può avere un impatto negativo significativo sulle prestazioni dell'applicazione e del database. Ci sono alcuni livelli di accesso ai dati che migliorano questo (UniDAC, AnyDac, ...), quindi l'utilizzo di componenti compatibili con DB può migliorare le prestazioni. Tuttavia, i componenti non compatibili con DB possono superare qualsiasi risultato.

Spetta allo sviluppatore decidere quale meccanismo utilizzare, perché, come ho detto, tutto dipende dal tipo di applicazione che si sta facendo e in quale ambiente funzionerà.

Answer 4

Aneddoto: un controllo di DB-aware volta incasinato nostro database InterBase: per indicare una o la data null 'vuota', il TcxDBDateEdit data di controllo di modifica (ExpressQuantumGrid) utilizza un valore negativo data, che rappresenta letteralmente "01/00/0000" .

Quindi, quando gli utenti hanno cancellato il campo di modifica della data nel modulo di immissione e hanno inviato questo valore nel database, i record sono diventati illeggibili (le istruzioni SELECT non sono riuscite).

Answer 5

Questo può essere un riporto dall'esperienza con Visual Basic. Come ricordo, anche Microsoft ha detto agli sviluppatori di non utilizzare i controlli compatibili con DB nel codice di produzione.

Delphi non ha mai avuto questo problema, ma come altri hanno detto, dipende dal tipo di progetto che si sta creando e dal fatto che si verifichino problemi di prestazioni.