37 messaggi dal 18 agosto 2006
Ciao a tutti,
ho una piccola curiosità, ma nell'era pre-ORM, quando si aveva un'applicazione che doveva in un submit persistere dati su 2 o più tabelle nel DB, che tecnica si usava?

Magari qualcuno ha ancora qualche applicazione che non fa uso di ORM e può spiegarmi la metodologia usata?

In effetti gli ORM sono diventati oramai quasi indispensabili nello sviluppo di un'applicazione, ma è un pò come fare i conti con la calcolatrice ossia si rischia veramente di utilizzarli anche in scenari semplicissimi dove il db è composto da non più di tre tabelle.

Potete aiutarmi a capire?

Grazie mille.
Daniele
io personalmente scrivevo DAL a raffica (Data Access Layer) cioè classi che facevano di fatto quello che oggi fanno gli ORM, ma tutto a manella, le insert, le select, gli update, le delete, ecc..

se ci sono operazioni su più tabelle la pratica più ovvia da sempre è l'uso di una transaction che contiene tutte le operazioni sul DB, se va bene tutto chiudi con una commit e i dati vengono applicati di fatto sul database, altrimenti un bel rollback e il db neanche si accorge di cosa stavi facendo...
37 messaggi dal 18 agosto 2006
Ciao dancerjude,
grazie per avermi risposto.
prendiamo per esempio la Insert.
Supponiamo di avere un ObjectModel costituito da un oggetto Persona che contiene una collezione di oggetti Contatto.

Adesso, un'ipotetica applicazione instanzia l'oggetto Persona ed aggiunge tre contatti di tipo mail alla collezione.

Ora il DAL cosa fa?

inserisce la Persona recupera l'id e lo utilizza per inserire i tre contatti?

Oppure passa al DB tutti i parametri sia della Persona che dei contatti e li fa persistere in un unica transazione?

Continuo ancora a non capire.

Grazie.
ai tempi antichi si facevano parecchie cose "poco pulite", tipo usare colonne non-identity e gestire a manella il max(id) (sempre con la sicurezza di una transazione per volta), oppure si può fare, nella stessa select una cosa tipo

INSERT INTO Table VALUES bla bla bla; 
SELECT @@IDENTITY;


tutto in una sqlcommand eseguita con executescalar e preso l'identity che ti ritorna (e che riguarda quella transaction), si possono poi eseguire gli altri insert...

questo è un modo, poi ce ne sono altri, ognuno si è "inventato" il suo ;-)

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.
Community
Ultimi messaggi
UTENTI ONLINE
In primo piano

I più letti di oggi

Media
In evidenza
MISC