In sintesi
In questa lezione viene introdotto il servizio di identificazione dei documenti, che consente di avere un metodo uniforme per definire le chiave primarie delle tabelle del database.
Nota: questo video corso è stato realizzato con la versione 4 di Instant Developer. Anche se i contenuti sono ancora attuali e sono utili per imparare ad utilizzare Instant Developer, alcune affermazioni sono di fatto superate. Per i dettagli e le ultime novità sulle funzionalità illustrate vi rimandiamo alla sezione di reference che viene tenuta aggiornata giornalmente.
In questa lezione introdurremo i servizi ai documenti. Come abbiamo visto precedentemente, ogni documento, appoggiandosi al framework, è in grado di compiere in autonomia delle funzioni complesse, come caricare o salvare tutte le sue parti sul database. In aggiunta a queste caratteristiche il framework mette a disposizione dei documenti un sistema estensibile per la creazione di servizi, come ad esempio, il servizio allegati, il servizio commenti e traduzioni, o il servizio proprietà estese, che vedremo meglio nelle prossime lezioni.
La maggior parte di questi servizi può funzionare se il documento supporta un metodo di identificazione standard, che consiste nell'utilizzare un unico campo come primary key della tabelle base, a cui deve essere associato il dominio DOCID. Questo dominio, che genera un campo carattere di lunghezza fissata a 20, viene riconosciuto dal framework che è quidni in grado di generare automaticamente delle stringhe di 20 caratteri univoche nel tempo e nello spazio come quella nell'esempio. Utilizzando questo metodo ci si può dimenticare della gestione delle primary key e delle foreign key perché saranno sempre in carico al framework. Ad esempio durante la duplicazione di un documento che utilizza DOCID, tutte le parti del nuovo documento avranno automaticamente un DOCID nuovo, inoltre verranno anche ricollegate fra loro correttamente.
Anche dal punto di vista della modellazione dati, la primary key di una tabella è un modo per identificare univocamente gli oggetti contenuti nella tabella, ma in più deve essere un modo invariante nel tempo e possibilmente nello spazio. Questo può essere ottenuto solo utilizzando una primary key "artificiale" come ad esempio un contatore, e non una delle proprietà dell'oggetto che oggi può essere univoca e domani potrebbe non bastare più. Il metodo DOCID è un evoluzione dell'uso contatore, perché è completamente acontestuale e non dipende da niente per garantire la sua univocità.
A fronte di queste considerazioni, Pro Gamma consiglia caldamente l'uso del metodo DOCID, metodo che dovrà essere abbandonato solo a fronte di una motivata inadeguatezza ad una situazione contingente, e con la consapevolezza che in questo modo ci si priva di molti servizi che potrebbero essere gestiti automaticamente dal framework dei documenti.
Per concludere facciamo un esempio. Modifichiamo la chiave della tabella articoli del database Northwind per supportare i DOC-ID, e proviamo l'applicazione. Come spesso succede quando si usano campi contatori, anche i campi DOCID non devono essere mostrati all'utente, ma verranno i riferimenti a tabelle padre dovranno essere impostati attraverso opportune Smart Lookup. Modifichiamo l'applicazione per nascondere il DOC-ID sui riferimenti agli articoli e riproviamo l'applicazione.
Servizio di identificazione
Servizio di identificazione
