Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DAL in C#: consigli vari

4 views
Skip to first unread message

Giulio Petrucci

unread,
Sep 13, 2006, 7:51:53 AM9/13/06
to
Slave a tutti,

[Premessa: se sono OT, vi prego di farmelo notare (e di consigliarmi il
ng in cui postare)]

Ho una pagina aspx che viene interrogata per ottenere dei dati presenti
in un DB (SQL Server). Il DB che ho (è solo per testare il tutto, ma
anche quello di produzione non sarà molto più complesso) ha un unica
tabella "Partecipante" (che indica tutti i partecipanti ad una
manifestazione) con 4 colonne: ID numerico (PK), cognome, nome, età. Ho
pensato di modellizzare questa entità con un oggetto Partecipante che
espone i valori delle quattro colonne come 4 proprietà. La mia idea è
quella di ritornare alla pagina aspx un array Partecipante[] da cui poi
questa estrae le info necessarie.

La mia domanda è: come posso strutturare l'object model (se di object
model si può parlare) del mio DAL (fisicamente implementato da una dll
sviluppata a parte)? Pensavo ad un oggetto-singleto cui fare la
richiesta di estrazione dei dati. Come potri chiamarlo? DBPartecipanti?
Ve lo chiedo perchè visto che la libreria la utilizzerà una terza parte
vorrei che anche i nomi fossero i più esplicativi possibile.

Altra questione: la connection string! Ho visto (in Visual Sudio Web
Developer) che le applicazioni hanno una cartella App_data (in cui
suppongo vada il mio DB) ed una Bin (in cui dovrebbe andare l'assembly
che realizza il mio DAL). Come posso far sapere al DAL in quale
locazione si trova il DB che deve interrogare, così da poter generare la
giusta connection string?

Grazie in anticipo,
Giulio

Raffaele Rialdi [MVP]

unread,
Sep 13, 2006, 5:54:40 PM9/13/06
to
> La mia domanda è: come posso strutturare l'object model (se di object
> model si può parlare) del mio DAL (fisicamente implementato da una dll
> sviluppata a parte)?

Non puoi partire da un DAL per modellare.
- Un object model è un modello di un problema reale e ne definisce le
caratteristiche essenziali.
- Il db è una mera persistenza dell'object model
- Il compito del DAL è quello di eliminare da tutto il sistema la conoscenza
del db come sistema di persistenza che un domani potrebbe essere su un altra
tipologia di archiviazione o più semplicemente con altro mezzo (per esempio
un web service)
A volte (ma non è detto che accada sempre) il DAL può mappare i dati nel tuo
object model, creandone di conseguenza le istanze.
Altre volte invece è conveniente avere un altro strato in mezzo che mappa
ciò che esce dal DAL sul tuo object model
Quello che può rendere l'idea sulla scelta delle due strade è quando gli
stessi dati del db possono dare oggetto a due entità differenti del tuo
object model ma non vuoi fare il requery doppio dal db.
Prendi cmq questo come caso particoalre ma da non sottovalutare.

> Pensavo ad un oggetto-singleto cui fare la
> richiesta di estrazione dei dati. Come potri chiamarlo?
> DBPartecipanti? Ve lo chiedo perchè visto che la libreria la
> utilizzerà una terza parte vorrei che anche i nomi fossero i più
> esplicativi possibile.

Questo sta a te, l'importante è che sei coerente con la nomeclatura.

> Altra questione: la connection string! Ho visto (in Visual Sudio Web
> Developer) che le applicazioni hanno una cartella App_data (in cui
> suppongo vada il mio DB) ed una Bin (in cui dovrebbe andare l'assembly
> che realizza il mio DAL). Come posso far sapere al DAL in quale
> locazione si trova il DB che deve interrogare, così da poter generare
> la giusta connection string?

Se usi quella generata da vs.net userai quella nella debug/release e così va
bene.
L'importante è ricordarsi che le modifiche vengono sovrascritte alla
compilazione successiva e quindi devi salvarti il file se ti servono quei
dati.

--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele

Giulio Petrucci

unread,
Sep 14, 2006, 4:19:30 AM9/14/06
to
Ciao Raffaele,

Raffaele Rialdi [MVP] ha scritto:


> Non puoi partire da un DAL per modellare.

[cut]


> A volte (ma non è detto che accada sempre) il DAL può mappare i dati nel tuo
> object model, creandone di conseguenza le istanze.

Ok, perfetto.
Dunque - questo è quanto ho afferrato - per modellare la tabella
"Partecipante" con 4 colonne, devo avere una classe "Partecipante" con 4
proprietà. Alla pagina aspx che interroga il mio DAL per avere i dati
giusti devo ritornare une array di Partecipante. Giusto?

> Se usi quella generata da vs.net userai quella nella debug/release e così va
> bene.

Questo potrebbe essere un problema.
Ti spiego: io sviluppo il DAL in C#, mentre la pagina aspx la viluppo
(io o un mio collega) usando VS Web Developer. Devo dunque copiare la
dll nella cartella Bin del progetto VSWD e il file .mdf in App_data? Se
è così devo cambiare la connection string (questo serve solo in fase di
sviluppo, perchè in produzione il DB del cliente starà
sperduto-nell'-universo-chissà-dove).

Ciao,
Giulio

Andrea Saltarello [UGIdotNET][MVP]

unread,
Sep 14, 2006, 6:21:06 AM9/14/06
to
>Ho una pagina aspx che viene interrogata per ottenere dei dati presenti in
>un DB (SQL Server). Il DB che ho (è solo per testare il tutto, ma anche
>quello di produzione non sarà molto più complesso) ha un unica tabella
>"Partecipante" (che indica tutti i partecipanti ad una manifestazione) con
>4 colonne: ID numerico (PK), cognome, nome, età. Ho pensato di modellizzare
>questa entità con un oggetto Partecipante che espone i valori delle quattro
>colonne come 4 proprietà. La mia idea è quella di ritornare alla pagina
>aspx un array Partecipante[] da cui poi questa estrae le info necessarie.

>La mia domanda è: come posso strutturare l'object model (se di object model
>si può parlare) del mio DAL (fisicamente implementato da una dll sviluppata
>a parte)? Pensavo ad un oggetto-singleto cui fare la richiesta di
>estrazione dei dati. Come potri chiamarlo? DBPartecipanti? Ve lo chiedo
>perchè visto che la libreria la utilizzerà una terza parte vorrei che anche
>i nomi fossero i più esplicativi possibile.

Giulio, direi che si potrebbe parlarne per taaaanto tempo <g> Provo a darti
la "big picture": in un mondo perfetto lo schema dati dell'applicazione è
proprio l'object model che stai realizzando, e *non* lo schema del db.
L'object model può essere modellato ispirandosi al pattern "Domain Model"
(http://www.martinfowler.com/eaaCatalog/domainModel.html ). Secondo la
formulazione "accademica" il DM contiene "both data and behaviour" quindi,
strettamente parlando, potrebbe contenere anche la logica di persistenza (e
robetta varia, come una implementazione di ActiveRecord), cioè esporre
direttamente i tipici metodi CRUD.
Poichè DM "lavora" bene con "Service Layer"
(http://www.martinfowler.com/eaaCatalog/serviceLayer.html ), io preferisco
considerare la persistenza un "servizio" e portarlo quindi fuori dal DM,
lasciandovi solo la parte di behaviour considerabile "business". In pratica,
cerco di rendere il mio DM quanto più "persistence ignorant" possibile. A
questo punto, mi ritovo quindi con delle CRUD "business" che sanno ricevere
ed "emettere" istanze del DomainModel applicandovi validazioni business e
sapendo comunicare col DAL. In uno scenario semplice, la GUI insiste
direttamente su queste CRUD per richiedere i servizi di persistenza. A
questo punto, si tratta di decidere come queste CRUD comunichino col DAL.
Per implementare il DAL, io tipicamente mi baso su una struttura "Separated
Interface" (http://www.martinfowler.com/eaaCatalog/separatedInterface.html )
e "Abstract Factory"
(http://www.dofactory.com/Patterns/PatternAbstract.aspx ): in pratica,
modello un DAL astratto in un assembly che verrà implementato da classi che
risiedono in assembly differenti, e predispongo una factory nel DAL astratto
che conosca il modo di reperire istanze del DAL concreto, e fornirle alle
CRUD di business, che quindi non dipendono da uno specifico DAL concreto
(che a questo punto è un reale Plugin).
In una ottica idiomatica, ti consiglio di non "passare" tra i layer degli
array, ma di usare dei contenitori + evoluti. Evita di usare List<T> nelle
API pubbliche (argomenti/valori di ritorno), poichè violeresti
(http://blogs.msdn.com/kcwalina/archive/2005/09/26/474010.aspx ) le Design
Guidelines di MS
(http://blogs.msdn.com/kcwalina/archive/2004/09/28/235232.aspx ). Se vuoi
definire dei tipi, usa Collection<T> come tipo base, altrimenti usa IList<T>
(chiuso, ovviamente, sulle entity del tuo DM) nelle API pubbliche quando
specifichi il tipo del contenitore.
Nei casi più esigenti, implemento una UnitOfWork
(http://www.martinfowler.com/eaaCatalog/unitOfWork.html ) che mi permette di
creare contesti transazionali e ridurre il numero di roundtrip verso il db,
eventualmente incapsulando nella UoW una IdentityMap
(http://www.martinfowler.com/eaaCatalog/identityMap.html ) per poter gestire
una cache degli oggetti già generati. In questi casi, la GUI dialoga con la
UoW. Se vuoi esagerare, puoi modellare UoW e IdentityMap come tipi astratti
e permetterne implementazioni concrete differenti, rendendole delle Strategy
(http://www.dofactory.com/Patterns/PatternStrategy.aspx ). Quest'ultima
scelta architetturale può risultare determinante se, per esempio, vuoi
condividere DM e ServiceLayer tra una gui windows ed una web, dovendo
basarti su differenti implementazioni del concetto di "sessione
applicativa".
Troppa carne al fuoco? Vuoi una scorciatoia? Te ne suggerisco 2:
1) Vieni al workshop "Architecture Days"
(http://www.ugidotnet.org/workshops/workshops_detail.aspx?ID=9ed3a5e7-a69c-4258-af7b-6ec3a8bcd025
) organizzato da UGIdotNET presso Microsoft, perchè le sessioni " Life
between the Domain Model and the Service Layer" e " Designing the Data
Access Layer" parlano proprio di questi argomenti, presentando uno scenario
reale (con codice "live" e diagrammi UML del caso) e arrivando anche ad
ipotizzare una soluzione basata su ORM
2) Se non puoi venire al workshop, scaricati l'applicazione che useremo come
demo (si chiama NSK, la trovi qui:
http://download.manageddesigns.it/nsk.aspx ): è open source sotto licenza
CPL, quindi puoi farne + o - ciò che vuoi. Tieni conto che la versione
*attualmente* online non include ancora le feature che stiamo implementando
per il workshop (ma è già un valido punto di partenza). Ovviamente, quando
saremo pronti aggiorneremo anche la versione online

ciao,

--
.A [Microsoft MVP .NET]


UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org

Read my blog at: http://blogs.ugidotnet.org/pape


David

unread,
Sep 14, 2006, 8:30:54 AM9/14/06
to
Andrea Saltarello [UGIdotNET][MVP] ha scritto:

Tanto e tutto molto interessante come sempre :-)

Che dire? Io mi salvo il post ed ogni tanto seguo i link... per quanto
riguarda il workshop "Architecture Days" dovrei esserci.

AndreaSaltarello++


Giulio Petrucci

unread,
Sep 14, 2006, 10:14:14 AM9/14/06
to
Ciao Andrea,

innanzitutto grazie per la risposta: una vera e propria "miniera" di
preziose risorse. Ti rispondo in maniera più "generale" perchè prima
vorrei documentarmi leggendomi per bene tutti i links che hai postato.

Andrea Saltarello [UGIdotNET][MVP] ha scritto:

> in un mondo perfetto lo schema dati dell'applicazione è
> proprio l'object model che stai realizzando, e *non* lo schema del db.

Si, ok (nel mio caso specifico, peraltro, la cosa è estremamente
semplice perchè ho solo un tipo da modellizzare).

> L'object model può essere modellato ispirandosi al pattern "Domain Model"

[cut]


> In pratica, cerco di rendere il mio DM quanto più "persistence ignorant" possibile.

Dunque, vediamo se ho capito: in pratica tu fai in modo che il tuo DM
(Domain Model) se ne freghi alla grande di tutto quanto abbia a che fare
la persistenza dei dati, giusto?

> A questo punto, mi ritovo quindi con delle CRUD "business" che sanno ricevere
> ed "emettere" istanze del DomainModel applicandovi validazioni business e
> sapendo comunicare col DAL.

Perfetto, dunque queste CRUD stanno immediatamente "sopra" al DB, ossia
alla persistenza dei dati? Quello che mi chiedo è: come le implemento?

> In uno scenario semplice, la GUI insiste
> direttamente su queste CRUD

Nel mio caso non ho una GUI ma una pagina aspx, ma credo che la sostanza
non cambi, giusto? quello che mi chiedo è: la GUI (o cmq il livello ri
presentation) può accedere direttamente alle CRUD?

> Quest'ultima
> scelta architetturale può risultare determinante se, per esempio, vuoi
> condividere DM e ServiceLayer tra una gui windows ed una web, dovendo
> basarti su differenti implementazioni del concetto di "sessione
> applicativa".

Questo ultimo tip mi servirà molto in futuro!

> Troppa carne al fuoco?

forse...
In generale direi di no, ma data l'estrema semplicità del mio problema
forse certi problemi sarebbe stato meglio non porseli nemmeno ;-)

> Vuoi una scorciatoia?

non necessariamente.

> Te ne suggerisco 2:

Addirittura!!! ;-)

> 1) Vieni al workshop "Architecture Days"

[cut]

Purtroppo in quei giorni non ci sarò. Vi "scaricherò" in seguito,
nagari. Solo una cosa: se potete realizzate anche un webcast dell'evento
(lo trovo un metodo molto utile)

> 2) Se non puoi venire al workshop, scaricati l'applicazione che useremo come
> demo (si chiama NSK, la trovi qui:
> http://download.manageddesigns.it/nsk.aspx ):

Ok, scaricherò, ma NSK sta per Northwind starter kit, giusto? Ora, oi
che non ho access installato come faccio?

Grazie ancora per l'esaustiva e-mail,
Giulio

Alberto Dallagiacoma

unread,
Sep 14, 2006, 2:13:05 PM9/14/06
to
Il presidente non sbaglia mai un colpo! :-)
Ottimo, Andrea! Anch'io mi salvo il post, e lo userò quando dovrò convincere
qualcuno che un'architettura non è una cosa che si realizza in quattro e
quattr'otto...
Io al workshop ci sarò quasi sicuramente: ci vediamo là.

Alberto
My Blog: http://blogs.ugidotnet.org/alby


Raffaele Rialdi [MVP]

unread,
Sep 14, 2006, 2:45:40 PM9/14/06
to
> Ok, perfetto.
> Dunque - questo è quanto ho afferrato - per modellare la tabella
> "Partecipante" con 4 colonne, devo avere una classe "Partecipante"
> con 4 proprietà. Alla pagina aspx che interroga il mio DAL per
> avere i dati giusti devo ritornare une array di Partecipante. Giusto?

Beh non necessariamente hai bisogno di mappare le 4 proprietà in 4 colonne
del db.
Il db consiste fondalmentalmente in persistenza e ricerca quindi le tabelle
del db vanno studiate in modo da sfruttare al meglio la ricerca ed essere
una buona persistenza per il tuo object model.

Per esempio puoi avere una classe con una dword e 32 proprietà boolean. Cosa
mettere sul db? Dipende se devi cercare flag per flag oppure ti basta
deserializzare l'informazione dentro la classe per ricreare l'oggetto.

Oppure ancora, ammettendo che ti serva fare query su 32 flag, usi dei campi
boolean? Tipicamente è meglio usare dei smalldatetime in modo da tenere
traccia _quando_ il flag è diventato 'attivo' e accettare il DBNull che
rappresenti il 'false'.

Insomma la corrispondenza tra db e classe è assolutamente poco ovvio e non
deducibile automaticamente.

In questo tipo di scenario, costruire un DAL che si limiti a creare un
oggetto specchio del risultato di una query è utile:
- per eliminare la conoscenza da parte della tua applicazione di cosa sia un
db
- per eliminare la differenza tra il type system del db e quello (nel nostro
caso) del framework
Ottenuta questa classe (le cui proprietà rispecchieranno 1:1 quelle del db),
finalmente arriva il mapping verso il tuo object model (si sono obsoleto ma
continuo sempre a chiamarlo così come i vecchi sacri testi di oop).


> Ti spiego: io sviluppo il DAL in C#, mentre la pagina aspx la viluppo
> (io o un mio collega) usando VS Web Developer. Devo dunque copiare la
> dll nella cartella Bin del progetto VSWD e il file .mdf in App_data?
> Se è così devo cambiare la connection string (questo serve solo in
> fase di sviluppo, perchè in produzione il DB del cliente starà
> sperduto-nell'-universo-chissà-dove).

Se la proprietà HttpContext.Current è diversa da null sei in una app web
altrimenti sei in una normale applicazione.
Questo ti può aiutare a distinguere i due casi.

David

unread,
Sep 15, 2006, 3:26:42 AM9/15/06
to
Raffaele Rialdi [MVP] ha scritto:

[cut]

Alcune considerazioni.

> Il db consiste fondalmentalmente in persistenza e ricerca quindi le
> tabelle del db vanno studiate in modo da sfruttare al meglio la ricerca ed
> essere una buona persistenza per il tuo object model.
>
> Per esempio puoi avere una classe con una dword e 32 proprietà boolean.
> Cosa mettere sul db? Dipende se devi cercare flag per flag oppure ti basta
> deserializzare l'informazione dentro la classe per ricreare l'oggetto.
>
> Oppure ancora, ammettendo che ti serva fare query su 32 flag, usi dei
> campi boolean? Tipicamente è meglio usare dei smalldatetime in modo da
> tenere traccia _quando_ il flag è diventato 'attivo' e accettare il DBNull
> che rappresenti il 'false'.
>
> Insomma la corrispondenza tra db e classe è assolutamente poco ovvio e non
> deducibile automaticamente.

In questo caso i framework O/R Mapper non ci servono a molto o sbaglio?

> In questo tipo di scenario, costruire un DAL che si limiti a creare un
> oggetto specchio del risultato di una query è utile:
> - per eliminare la conoscenza da parte della tua applicazione di cosa sia
> un db
> - per eliminare la differenza tra il type system del db e quello (nel
> nostro caso) del framework
> Ottenuta questa classe (le cui proprietà rispecchieranno 1:1 quelle del
> db), finalmente arriva il mapping verso il tuo object model (si sono
> obsoleto ma continuo sempre a chiamarlo così come i vecchi sacri testi di
> oop).

In questo caso possiamo avere dei vantaggi utilizzando degli ORM.

E' giusto?

David


Giulio Petrucci

unread,
Sep 15, 2006, 3:58:48 AM9/15/06
to
Ciao Raffaele,

Raffaele Rialdi [MVP] ha scritto:

> Beh non necessariamente hai bisogno di mappare le 4 proprietà in 4 colonne
> del db.

[cut]


> Insomma la corrispondenza tra db e classe è assolutamente poco ovvio e non
> deducibile automaticamente.

Ok, capisco il discorso, anche se faccio fatica a "figurarmene" le
dinamiche... la situazione con cui ho a che fare è molto semplice: ho un
DB in cui ogni tanto vengono aggiunti/tolti dei nominativi (la famosa
tabella con 4 campi), e una pagina aspx che deve - in sostanza -
restituire un elenco di tutte le righe del DB. Ecco perchè, nel mio
caso, la corrispondenza db-class è assolutamente ovvia ;-)

> Se la proprietà HttpContext.Current è diversa da null sei in una app web
> altrimenti sei in una normale applicazione.

preziosa indicazione!

Ciao,
Giulio

Raffaele Rialdi [MVP]

unread,
Sep 15, 2006, 5:23:45 AM9/15/06
to
>> Insomma la corrispondenza tra db e classe è assolutamente poco ovvio
>> e non deducibile automaticamente.
>
> In questo caso i framework O/R Mapper non ci servono a molto o
> sbaglio?

Gli ORM mapper più complessi richiedono che il mapping tra tabella del db e
object model sia fatto tramite un file descrittore (xml).
L'uso di questo sistema fa 'saltare' il passaggio intermedio della classe
che mappa 1:1 con il db e l'ORM classico qui non serve più a molto.
In questo scenario servirebbe qualcosa che ti permetta di definire il
mapping tra due classi dotnet. Questo è un task più semplice visto che il
type system è il medesimo, non richiede la generazione di sql (che nei casi
più complessi non è affatto semplice) ed si realizza in modo piuttosto
semplice tramite reflection.

Io credo (come ho già detto fin dalla scorsa PDC) che questo sia il modo
giusto di usare DLinq, cioè quello di creare un DAL e non un object model.
Nei casi più semplici (vedi problema di Giulio) le classi generate da DLinq
coincidono con il suo object model e il gioco è già concluso.
Il rischio è che DLinq venga usato male e si definisca l'object model come
conseguenza dell'estrazione dei dati e non come mezzo per istanziare un
object model preesistente.
Come tutte le cose si potrà usare bene o male ... sta a noi fare la
differenza.


>> Ottenuta questa classe (le cui proprietà rispecchieranno 1:1 quelle
>> del db), finalmente arriva il mapping verso il tuo object model (si
>> sono obsoleto ma continuo sempre a chiamarlo così come i vecchi
>> sacri testi di oop).
>
> In questo caso possiamo avere dei vantaggi utilizzando degli ORM.

Un ORM classico può fare questo in modo semplice ma come dicevo prima l'ORM
non si ferma solo a questo.

Raffaele Rialdi [MVP]

unread,
Sep 15, 2006, 5:25:30 AM9/15/06
to
> Ok, capisco il discorso, anche se faccio fatica a "figurarmene" le
> dinamiche... la situazione con cui ho a che fare è molto semplice: ho
> un DB in cui ogni tanto vengono aggiunti/tolti dei nominativi (la
> famosa tabella con 4 campi), e una pagina aspx che deve - in sostanza
> - restituire un elenco di tutte le righe del DB. Ecco perchè, nel mio
> caso, la corrispondenza db-class è assolutamente ovvia ;-)

Certo che è possibile che ci sia corrispondenza 1:1 tra OM e db ma secondo
me è sempre necessario fare un sforzo addizionale e pensare al problema
ignorando per un attimo lo schema del db scrivendo le classi in modo che
rappresentino un modello di un problema reale. Se poi coincide, tanto
meglio.

Andrea Saltarello [UGIdotNET][MVP]

unread,
Sep 15, 2006, 5:34:28 AM9/15/06
to
> Io credo (come ho già detto fin dalla scorsa PDC) che questo sia il modo
> giusto di usare DLinq, cioè quello di creare un DAL e non un object model.
> Nei casi più semplici (vedi problema di Giulio) le classi generate da
> DLinq coincidono con il suo object model e il gioco è già concluso.
> Il rischio è che DLinq venga usato male e si definisca l'object model come
> conseguenza dell'estrazione dei dati e non come mezzo per istanziare un
> object model preesistente.
> Come tutte le cose si potrà usare bene o male ... sta a noi fare la
> differenza.
>
>
Raf, il problema non è quello che dici tu o che posso dire io, bensì quello
che dice Microsoft. E Microsoft dice che le classi generate del DLinq *sono*
il domain model. E tutta la documentazione, e gli articoli su MSDN, e i blog
del team, e lo stesso Visual Studio "comunicheranno" questa affermazione.
Basterebbe che Microsoft avesse la stessa umiltà che Luca Bolognese (che in
fondo è "solo" il Program Manager) ha dimostrato affermando, a PDC, che
"DLinq non vuole essere un ORM full-featured". Come ho detto sin da allora
(e continuo a ripetere), IMHO DLinq è decisamente una occasione persa.
Peccato.


--
.A [Microsoft MVP .NET]

UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org

Raffaele Rialdi [MVP]

unread,
Sep 15, 2006, 7:37:59 AM9/15/06
to
> Raf, il problema non è quello che dici tu o che posso dire io, bensì
> quello che dice Microsoft. E Microsoft dice che le classi generate
> del DLinq *sono* il domain model. E tutta la documentazione, e gli
> articoli su MSDN, e i blog del team, e lo stesso Visual Studio
> "comunicheranno" questa affermazione. Basterebbe che Microsoft avesse
> la stessa umiltà che Luca Bolognese (che in fondo è "solo" il Program
> Manager) ha dimostrato affermando, a PDC, che "DLinq non vuole essere
> un ORM full-featured". Come ho detto sin da allora (e continuo a
> ripetere), IMHO DLinq è decisamente una occasione persa. Peccato.

Andrea, concordo assolutamente che questo sia l'atteggiamento di Microsoft.
MS deve spingere cose come il dataset, altrimenti si taglia via una fetta
enorme di mercato.
Però questo non significa che quella tecnologia si usi solo in quel modo.

Per quel poco che ho visto fin'ora DLinq è *anche* utilizzabile per fare le
cose per bene.
DLinq di fatto ti consente di eseguire query, filtri, grouping, etc. su una
generica fonte di dati e soprattutto togliere di mezzo la differenza del
type system.

Io lo trovo comodo per la generazione di classi che mi caricano in un type
system familiare i dati del db, già filtrati, ordinari, etc. etc.
Il "result-object" che ottengo può servire a reidratare diverse parti
dell'object model e questo è molto comodo per fare caching, lazy-load, etc.

Ok, questo non sta scritto ancora su nessun libro ma io sono un testone
bastian contrario e anti-mode :-)

Se poi preferisci lavorare con NHibernate, va bene lo stesso.... questione
di gusti.
A me non piace avere quel malefico proxy in mezzo ed è per questo che lo
digerisco poco. Mi sono sempre scritto object model puliti, intonsi e
strong-typed fin dall'epoca COM quando mi sono scritto la mia generica
classe di collection (ma strong-typed) con ATL. Con tutto ciò non metto
minimamente in dubbio l'efficacia di NHibernate.
Ripeto... questione di gusti.


--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -

http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele

Giulio Petrucci

unread,
Sep 15, 2006, 9:13:41 AM9/15/06
to
Ok, è giunto il momento di fare l'update del vocabolario:

[cut]

potreste gentilmente spiegarmi il significato dei seguenti termini:

DLinq,
ORM,
PDC,
NHibernate

Scusate la pedanteria e la "banalità" delle questioni, ma questo per me
è un "nuovo mondo", dunque più cose imparo (e prima le imparo) e meglio è.

Grazie in anticipo,
Giulio


Andrea Saltarello [UGIdotNET][MVP]

unread,
Sep 15, 2006, 9:24:42 AM9/15/06
to
> Andrea, concordo assolutamente che questo sia l'atteggiamento di
> Microsoft.
> MS deve spingere cose come il dataset, altrimenti si taglia via una fetta
> enorme di mercato.
> Però questo non significa che quella tecnologia si usi solo in quel modo.
>
concordo

> Per quel poco che ho visto fin'ora DLinq è *anche* utilizzabile per fare
> le cose per bene.
> DLinq di fatto ti consente di eseguire query, filtri, grouping, etc. su
> una generica fonte di dati e soprattutto togliere di mezzo la differenza
> del type system.
>

Vero, però pensa quanto sarebbe bello poter eseguire queste query
direttamente a livello business, evitando "trasformazioni" tra differenti
object model (quello "DM" e quello "DAL"). Finchè si tratta di grafi
semplici, questa trasformazione è una operazione triviale, ma su grafi
complessi rischia di diventare una specie di "deep copy" tutt'altro che
banale o poco costosa.

> Io lo trovo comodo per la generazione di classi che mi caricano in un type
> system familiare i dati del db, già filtrati, ordinari, etc. etc.
> Il "result-object" che ottengo può servire a reidratare diverse parti
> dell'object model e questo è molto comodo per fare caching, lazy-load,
> etc.
>
> Ok, questo non sta scritto ancora su nessun libro ma io sono un testone
> bastian contrario e anti-mode :-)
>

beh, direi che caching e lazy load sono contenuti nel "minimo sindacale" che
ci si aspetta da qualunque cosa sia (o assomigli ad) un ORM. Sulla comodità
non si discute, ma il problema è che di fatto poi ti devi reimplementare
entrambe (almeno il lazy load) anche a livello di Domain Model. Se DLinq
avesse mappato direttamente quest'ultimo, non ce ne sarebbe stato bisogno.

> Se poi preferisci lavorare con NHibernate, va bene lo stesso.... questione
> di gusti.
> A me non piace avere quel malefico proxy in mezzo ed è per questo che lo
> digerisco poco. Mi sono sempre scritto object model puliti, intonsi e
> strong-typed fin dall'epoca COM quando mi sono scritto la mia generica
> classe di collection (ma strong-typed) con ATL. Con tutto ciò non metto
> minimamente in dubbio l'efficacia di NHibernate.
> Ripeto... questione di gusti.

Raf, qui non si sta parlando di: mode, gusti o Hibernate. Chi se ne frega di
Hibernate. Il problema è (allo stato attuale delle cose) che non avremo un
ORM *vero* integrato nel FX, ed è un peccato, perchè.sarei il primo a
desiderare che DLinq lo diventasse, come ho espresso qui tempo addietro:
http://blogs.ugidotnet.org/pape/archive/2006/06/23/DLinqStrikesBack.aspx
Chi oggi usa Hibernate lo fa perchè offre il rapporto feature/prestazioni
migliore, sapendo che non è (nemmeno lontanamente) perfetto. Ecco, DLinq
poteva essere migliore di Hibernate, potendo contare sul supporto del
vendor, che può modificare: linguaggio/compilatore, librerie e runtime a
piacimento (un vantaggio strategico non indifferente). E' type safe a
compile-time: Hibernate non potrà mai esserlo. Può lavorare direttamente a
contatto con librerie e runtime, mentre Hibernate deve ricorrere a dei
proxy. Che ti devo dire? Forse, mi ero semplicemente lasciatoilludere da
ObjectSpaces :-)

--
.A [Microsoft MVP .NET]

UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org

David

unread,
Sep 15, 2006, 9:30:41 AM9/15/06
to
Giulio Petrucci ha scritto nel messaggio:

> Ok, è giunto il momento di fare l'update del vocabolario:
>
> [cut]
>
> potreste gentilmente spiegarmi il significato dei seguenti termini:

> ORM,
Object/Relational Mapping...
http://en.wikipedia.org/wiki/Object-relational_mapping

> DLinq,
Non ho ancora capito se considerarlo un ORM oppure no... Comunque ti
riporto il linq alle specifiche:
http://msdn.microsoft.com/data/linq/

> PDC,

PDC è l'abbreviazione di "Microsoft Professional Developers Conference"...
Link:
http://msdn.microsoft.com/events/pdc/

> NHibernate
E' il portingo dell'ORM Hibernate (per Java) in .NET:
http://www.nhibernate.org

HTH,
David


Raffaele Rialdi [MVP]

unread,
Sep 15, 2006, 10:01:01 AM9/15/06
to
>> Però questo non significa che quella tecnologia si usi solo in quel
>> modo.
> concordo

:)

> Vero, però pensa quanto sarebbe bello poter eseguire queste query
> direttamente a livello business, evitando "trasformazioni" tra
> differenti object model (quello "DM" e quello "DAL"). Finchè si
> tratta di grafi semplici, questa trasformazione è una operazione
> triviale, ma su grafi complessi rischia di diventare una specie di
> "deep copy" tutt'altro che banale o poco costosa.

Da una parte concordo pienamente. Dall'altra sono perplesso di come sarebbe
stato "semplice" creare il mapping (che era l'oggetto delle perplessità su
ObjectSpaces dello stesso Bolognese due/tre anni fa). Mappare due classi
dotnet è decisamente più triviale.
Ho visto che nell'ultima CTP c'è il designer Linq per fare il mapping ma
devo ancora capire cosa crea.

Ad ogni modo credo che si potrà fare quello che dici in quanto le classi di
base sono tutte aperte ad estensioni. Io sto guardando per il momento solo
la parte che riguarda l'estensione al linguaggio e ho già diverse idee per
sfruttarlo in altri scopi.
La sua applicazione Linq non ho fretta di approfondirla subito. Voglio prima
capire bene come funge quello che sta sotto.


> beh, direi che caching e lazy load sono contenuti nel "minimo
> sindacale" che ci si aspetta da qualunque cosa sia (o assomigli ad)
> un ORM. Sulla comodità non si discute, ma il problema è che di fatto
> poi ti devi reimplementare entrambe (almeno il lazy load) anche a
> livello di Domain Model. Se DLinq avesse mappato direttamente
> quest'ultimo, non ce ne sarebbe stato bisogno.

Sono daccordo che sarebbe stato bello almeno poter scegliere ma questo
mapping lo vedo meno oneroso che lavorare sul proxy per accedere al mio OM.
Se accedo centomila volte ai miei oggetti, il tempo bruciato dal proxy è
IMHO un vero spreco.
Certo che se poi l'OM lo usiamo solo per fare un banale binding, allora non
fa alcuna differenza.

So che DLinq poteva fare di più, ma preferisco farmi quello che manca a
manina invece di incasinarmi la vita con gli xml di mapping, le classi
proxy, la unit of work, etc.... ma il problema è tutto mio :)


> Raf, qui non si sta parlando di: mode, gusti o Hibernate. Chi se ne
> frega di Hibernate. Il problema è (allo stato attuale delle cose) che
> non avremo un ORM *vero* integrato nel FX, ed è un peccato,
> perchè.sarei il primo a desiderare che DLinq lo diventasse, come ho
> espresso qui tempo addietro:

[...]

Il fatto che Linq abbia una architettura così estensibile mi fa stare
ottimista. Al momento non so dirti però se questo può colmare i vuoti.

> E' type safe a
> compile-time: Hibernate non potrà mai esserlo.

Questo per me è uno dei motivi più importanti per cercare di usare DLinq a
costo di dovermi scrivere qualcosa a manina.

> Può lavorare
> direttamente a contatto con librerie e runtime, mentre Hibernate deve
> ricorrere a dei proxy. Che ti devo dire? Forse, mi ero semplicemente
> lasciatoilludere da ObjectSpaces :-)

nel club siamo in tanti :)

--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -

http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele

David

unread,
Sep 15, 2006, 11:25:51 AM9/15/06
to
Andrea Saltarello ha scritto:

[cut]

> Secondo la formulazione "accademica" il DM contiene "both data and
> behaviour" quindi, strettamente parlando, potrebbe contenere anche la

> logica di persistenza...

> Poichč DM "lavora" bene con "Service Layer"

> (http://www.martinfowler.com/eaaCatalog/serviceLayer.html ), io preferisco
> considerare la persistenza un "servizio" e portarlo quindi fuori dal DM,
> lasciandovi solo la parte di behaviour considerabile "business". In

> pratica, cerco di rendere il mio DM quanto piů "persistence ignorant"
> possibile.

[cut]

Ti ho scritto anche tramite il "Contact" del tuo blog, ma non ho ricevuto
nessuna risposta e riprovo qui:

Ho capito, anche vedendo come hai strutturato NSK, che tu sei un "fans"
dell'"Anemic Domain Model". Mi piacerebbe sapere cosa ne pensi di quello che
dice Martin Fowler qui:

http://www.martinfowler.com/bliki/AnemicDomainModel.html

Grazie mille,
David


Lorenzo Barbieri [MVP]

unread,
Sep 16, 2006, 5:24:28 PM9/16/06
to
"Giulio Petrucci" <gpe...@sisisiassolutamente.si> wrote in message
news:eee8u1$iec$3...@news.task.gda.pl...

>potreste gentilmente spiegarmi il significato dei seguenti termini:
>DLinq,ORM,PDC,NHibernate

Scusa... ma se vuoi davvero imparare perchè non provi almeno a fare prima
almeno un giro su google o sul nuovo live.com?
Poi chiedi quello che non ti è chiaro...
--
Lorenzo Barbieri
MVP Windows - Virtual Machines, MCT, MCPD EA,Web,Win, MCITPro DBA
IT: http://www.geniodelmale.info
EN: http://www.lorenzobarbieri.info
VSTS: http://teamsystemrocks.com/blogs/barbilor/default.aspx

Andrea Saltarello [UGIdotNET][MVP]

unread,
Sep 18, 2006, 4:26:35 AM9/18/06
to
> Ho capito, anche vedendo come hai strutturato NSK, che tu sei un "fans"
> dell'"Anemic Domain Model". Mi piacerebbe sapere cosa ne pensi di quello
> che dice Martin Fowler qui:
> http://www.martinfowler.com/bliki/AnemicDomainModel.html
>
David, faccio innanzitutto un paio di precisazioni:
- Non mi ritengo un fan dei domain model anemici
- conosco ormai quasi a memoria quel post di Martin, e continuo a pensare
che una cantonata può prenderla chiunque (quindi anche lui <g>)

In breve, è mia opinione che definire "anemico" un DM sia equivalente e
definire "trasparente" l'acqua. IMHO un DM *è* anemico esattamente come
l'acqua è trasparente, si tratta "solo" di capire *quanto* sia anemico. E'
una considerazione che ho già espresso qui:
http://blogs.ugidotnet.org/pape/archive/2006/08/31/47055.aspx

Per intenderci, non penso alle entità del DM come a dei semplici contenitori
dati (ergo, solo proprietà) e concordo sul "famigerato" "...both data and
behaviour...", però in una ottica di PI un certo (seppur minimo) livello di
anemia del DM è imprescindibile. Lo stesso Martin conclude il post da te
citato con la frase: "If all your logic is in services, you've robbed
yourself blind." IMHO si tratta di rendersi conto che ha scritto "all", cioè
"tutti". "Portar fuori" dal DM la logica di persistenza non significa averlo
"derubato" di tutti i servizi. Ecco perchè definire un DM semplicemente come
"anemico" senza specificare *quanto* lo sia lascia un po' il tempo che
trova. Se ne potrebbe parlare per ore, ed infatti... Lo farò nella sessione
" Life between the Domain Model and the Service Layer" al workshop
"Architecture Days":
http://www.ugidotnet.org/workshops/workshops_detail.aspx?ID=9ed3a5e7-a69c-4258-af7b-6ec3a8bcd025
<g>

David

unread,
Sep 18, 2006, 7:01:45 AM9/18/06
to
Andrea Saltarello ha scritto:

[cut]

Grazie per le risposte sempre precise e puntuali.

> Se ne potrebbe parlare per ore, ed infatti... Lo farò nella sessione "
> Life between the Domain Model and the Service Layer" al workshop
> "Architecture Days":
> http://www.ugidotnet.org/workshops/workshops_detail.aspx?ID=9ed3a5e7-a69c-4258-af7b-6ec3a8bcd025
> <g>

Io ci sarò :-)


0 new messages