[Tutti] Allora...visto che dobbiamo parlare di ORM, vediamo un po' di iniziare capendo se li usate, perchè si perchè no, ecc.....
.mark - Marco Trova says:
ah, sì
Mario says:
[tutti] mi consigliate come impostare il messenger (colori, sfondo) mi sta gia' venendo il mal di testa a leggere dal monitor
.mark - Marco Trova says:
[tutti] io sì, ed un paio per dirla tutta!
MarcoDes says:
[Tutti] io decisamente sì
ema says:
[Tutti] il Guru è Janky,.....quindi sarà lui maggiormente bombardato dalle domande
.mark - Marco Trova says:
[tutti] anche insieme!
luke says:
[Tutti] io uso solo NH
Marco says:
[Mario] se vuoi ti passo lo sfondo con i pesciolini
Giangi has been added to the conversation.
janky says:
tutti - io ho usato NH in .NET e anche Hibernate in Java
janky says:
c'è qualcuno che viene dal mondo java?
Giangi says:
cia a tutti
ema says:
[Tutti] prima di tutto: c'è qualcuno che non li usa per scelta?
Mario says:
[tutti] io un po java fui
janky says:
interessante questione posta da emanuele...
MarcoDes says:
[ema] in azienda alcuni PM sono riluttanti perché sfruttano ancora moltissimo le storeproc e fanno risiedere molta logica su DB
janky says:
c'è qualcuno che non li usa perchè "non gli piacciono" per qualsiasi motivo?
Giangi says:
[ema] io ho sempre avuto sempre un po' di scetticismo verso gli orm
Mario says:
[tutti] io ad esempio, di recente non li ho usati per scelta
luke says:
[tutti] io uso NH ma a volte sono dubbioso
janky says:
Ciao gianluca, non ti avevo riconosciuto
.mark - Marco Trova says:
[tutti] io ho consigliato un mio collega di usarli un paio di anni fa.. perchè faceva cool e sono un po' sadico.. poi il suo entusiasmo mi ha trascinato..
ema says:
[MarcoDes] ma non esistono ORM che supportano le sp?
Giangi says:
ciao janky
ema says:
[Mario] perchè?
Mario says:
[tutti] dovendo creare anche il dv ho preferito progettare prima questo e poi usare ado.net connesso per accedere
Marco says:
[MarcoDes] si esistono, per esempio NetTiers
Melchio (1/3) says:
[MarcoDes] è proprio vero...è di pochi giorni fa una disputa (accesa) in azienda sul perchè è o non è il caso di far risiedere tutta la logica di business sul db
Mario says:
[tutti] dv sta per database (errore di stampa
MarcoDes says:
[ema] NH le supporta, ad esempio, il concetto è che spesso le storeproc utilizzate richiedono informazioni aggiuntive (oltre alla entity da persistere), quali ad es. il contesto (utente, funzionalità, ecc.ecc.)
Marco says:
[ema] nettiers
janky says:
anche NH supporta SP
Melchio (1/3) says:
[MarcoDes] come direbbe Mughini...*aborro* questa soluzione!!!
luke says:
[Tutti] io sono del partito contro le SP, non sopporto la logica lato db
janky says:
sto aggiungendo rosalba
fiorerosalba@tiscali.it (E-mail Address Not Verified) has been added to the conversation.
MarcoDes says:
[Melchio] Credo che si tratti di un problema comune a tutte le app di un certo livello che partono da db-legacy
ema says:
[MarcoDes] capisco....molti sono in una situazione simile...è + comodo gestire le modifiche cambiando una sp
Mario says:
[janky] usare nh sembra ridurre il db ad un semplice contenitore di dati rinunciando in tal modo a tutte le automazioni che questo puo' offire
Giangi says:
[tutti] secondo voi meglio gli orm o generatori di codice per generare lo strato db?
MarcoDes says:
[ema] già, purtroppo imho il salto più grosso non è verso l'uso di un orm, ma verso una SOA
janky says:
[Mario] specifica...a quali riduzioni ti riferisci?
Mario says:
[janky] ad esempio relazioni, integrita, vincoli ecc..
ema says:
[MarcoDes] hai ragione!!!
janky says:
per esperienza...nessuna di queste feature viene persa per l'uso di un ORM
MarcoDes says:
[Mario] scusami... ma in che modo questi aspetti sono limitati da un ORM
.mark - Marco Trova says:
[janky] mi se che devi confutare un po' di misunderstanding
janky says:
mi sa di si...
janky says:
janky says:
mi piacerebbe darvi qualche aspetto degli ORM che probabilmente presento anche domani
ema says:
[Tutti] Quanti non usano gli ORM perchè poco performanti? (è una scusa che sento spesso)
Mario says:
[marcodes] attenzione, non ho detto che sono limitati, ma dalle sessioni webcast si evinche che tutta la logica debba essere inclusa nell'applicazione e quindi per conseguenza si debba evitare di memorizzarla nel db
.mark - Marco Trova says:
orm cambia il vostro modo di lavorare, non abbiate paura di usarli..
MarcoDes says:
[Mario] e io ripeto... secondo me il DB deve fare il DB e la logica deve trovarsi altrove
janky says:
gli ORM sono nati soprattutto per affiancare il problema della persistenza legato a strutture object oriented particolarmente complesse
Mario says:
[marcodes] su questo non sono d'accordo
MarcoDes says:
[ema] ti cito una frase di Gavin King che ho detto durante la mia sessione a dotnetmarche: "quanti non usano C# perché poco performante rispetto ad un software scritto in assembler "
.mark - Marco Trova says:
io uso nhibernare su cuyahoga ed è più velOCE DI DOTNENUKE!
janky says:
se pensate ad un Domain Model (la cui definizione non è per niente banale) il solo fatto di usare refernce incrociate penalizza fortemente la scrittura di un layer di accesso ai dati
MarcoDes says:
[Mario] come mai
ema says:
[ MarcoDes, MArio] ma secondo voi un costraint di FK è una regola di business?
Mario says:
[marcodes] ad esempio, se devi inserire una riga in una tabella a dopo che e' stata inserita una riga in una tabella b a chi lo fai fare il lavoro ?
.mark - Marco Trova says:
ragazzi vi devo lasciare.. ho 38 di febbre.
Michele says:
ciao Marco, guarisci presto
Mario says:
[ema] secondo me dipende..
luke says:
[ema] secondo me no
janky says:
wow...sotto le coperte! marcuccio!
Marco says:
ciao mark
luke says:
ciao Marco in bocca al lupo
fiorerosalba@tiscali.it (E-mail Address Not Verified) says:
ciao mark
.mark - Marco Trova says:
viva la tachipirina!
Giangi says:
ciao marco, buon riposo!
ema says:
[.mark] ciao marko. Peccato...ma rimettiti in forma!!
janky says:
rimetti in fORMa
janky says:
huahuahua
Michele says:
LOL
.mark - Marco Trova says:
.mark - Marco Trova has left the conversation.
ema says:
[Mario/Luke] perchè dipende, e perchè no?
MarcoDes has left the conversation.
Mario says:
[janky] una domanda alla quale ancora non sono riuscito a trovare una risposta univoca: " dovendo creare ex novo un db e avendo in mente NH come battezzi le tabelle ? singolare o plurale ?
Michele says:
[janky] questa e' filosofica
janky says:
[Mario] a prescindere da NH...sempre singolare...ma è una mia linea guida...
luke says:
[ema] perchè una FK migliora il lavoro della BR
luke says:
[ema] che però vive e "funziona" anche senza
MarcoDes has been added to the conversation.
Mario says:
[janky] pero' non ti suona strano ?
janky says:
[mario] all'inizio si...poi ho trovato che sia la scelta più giusta poich
janky says:
[mario] se non sbaglio ho trovato conferma anche in qualche testo sacro...ma adesso non ricordo...
ema says:
[luke] si sono d'accordo con te, con un ma perchè non usare comunque le feature messe a disposizione dal db?
janky says:
[tutti] c'è qualcuno che si è trovato costretto a usare ORM perchè il Modello che si era disegnato era diventato piuttosto complesso?
janky says:
(la domanda è molto tendenziosa......)
ema says:
[janky] per me è stato + o meno cosi: sono partito facendo le cose a mano, poi mi sono detto "pirla" cosi perdi più tempo a mettere insieme gli oggetti per persistere i dati sul db che a scrivere il "business" dell'applicazione...quindi ho provato nh...ed è stato amore
Mario says:
[janky] ti rigiro la domanda. hai iniziato ad usare nh con un modello semplice ?
janky says:
[mario] quando ho cominciato a usare NH avevo già da tempo lasciato perdere i dataset e avevo iniziato a usare una modellazione per Domain Model pura
janky says:
[mario] ed è li che mi sono accorto pian piano...che il lavoro da fare era troppo
Mario says:
[janky] diciamo che sono piu' o meno nella tua situazione, pero' trovo una difficolta'
janky says:
[mario] caricare una semplice struttura con un paio di reference presenta delle difficoltà enormi...non è uno scherzo
Maurizio @Roma has been added to the conversation.
janky says:
[mario] in merito alla persistenza transitiva...in merito al caricamento dei dati...quante select faccio, faccio le join...la metto non la metto
janky says:
[mario] ed è li che mi sono accorto che...o con un Domain Model usi un tool per la parte di persistenza che ti aiuti
janky says:
oppure devi rimanere con i tuoi dataset...che nella modellazione in TableModule...vanno STRABENISSIMO
Mario says:
[janly] potresti riassumere il tuo iter formativo su nh ?
janky says:
[mario] bella domanda
janky says:
[mario] all'inizio è stata veramente dura...ma perchè mi ostinavo a cercare sempre e solo documentazione per .NET
Mario says:
[janky] lo so, io non so da dove iniziare. i tutorial e gli articoli sono troppo banali o generici
Mario says:
[janly] idem
janky says:
[mario] il salto l'ho fatto quando ho cominciato a leggere il libro di gavin King...il papà...che pur essendo scritto per java...è labibbia
MarcoDes says:
[Mario] leggi hibernate in action di gavin king
MarcoDes says:
[Mario] ti apre veramente gli occhi
MarcoDes says:
[Mario] un'altra ottima fonte è la reference di Hibernate 3 per java
janky says:
[tutti] adesso è uscita la seconda edizione...ma va molto in la con l'aggancio al mondo java, soprattutto con JBoss e Seam...
Mario says:
[janky] cosa intendi per TableModule ? (scusa se la domanda e' stupida ma non l'ho mai sentito=
Maurizio @Roma has left the conversation.
janky says:
[mario] considera che i pattern per la modellazione dei layer di dominio sono tre: come catalogato da Fowler
Maurizio @Roma has been added to the conversation.
janky says:
[mario] TRansaction script:assimilabile al procedurale
janky says:
[mario] TableModule, un disegno molto data centrico (come i dataset)
Giangi says:
[janky] ma esistono valide alternative a NH? Spesso ORM signigica Hibernate....
janky says:
[mario] e il Domain Model che è puro OO
janky says:
[giangi] assolutamente si
janky says:
[giangi] a pagamento credo che uno dei più tosti sia Genome
MarcoDes says:
[mario] tra l'altro in .net 2.0, grazie al fatto che i typed dataset ora generano classi parziali, è stato fornito un supporto veramente valido al pattern table module
MarcoDes says:
[mario] pardon, in VS2005
janky says:
[tutti] è proprio quando si passa ad un modello: Domain Model che arrivano i guai per scrivere a mano lo strato di accesso ai dati, ecco il perchè della nascita degli ORM
MauriD [MVP SQL Server] has been added to the conversation.
Michele says:
[tutti] ho sentito parlare bene di Wilson ORM, qualcuno l'ha provato?
janky says:
non tanto il fatto che ti risparmi di scrivere una INSERT a manina
MauriD [MVP SQL Server] says:
ciao a tutti
janky says:
Ciao Davide!
MauriD [MVP SQL Server] says:
Michele says:
ciao Davide
ema says:
[Tutti] E' entrato anche Davide (esperto di SQL ) ci può dare la sua visione sugli ORM
Giangi says:
ciao davide
luke says:
ciao
Maurizio @Roma says:
ciao Davide
janky says:
dicevo...il discriminante per l'uso di un ORM è il modello del Domain Layer
janky says:
tra i tre che vi stavo elencando
janky says:
sempre che chi scelga di modellare un domain model lo stia facendo secondo i canoni corretti
ema says:
[Davide] prima ci si chiedeva perchè li usi o perchè non li usi...qual'è la tua visione? (visto che tu vedi le cose dall'altro lato ) (quello del db intendo )
janky says:
e io che pensavo di finire a mezzanotte...
MauriD [MVP SQL Server] says:
eheh
MauriD [MVP SQL Server] says:
io NON uso un ORM...ho provato ma non li vedo bene...spiego subito il perchè in tre punti veloci veloci
MauriD [MVP SQL Server] says:
premetto però che sono _ovviamente_ daccordo sul fatto che l'object model va creato secondo i canoni della OOD (Domain Model ad esempio) ed in nessun caso (allo stato attuale delle cose) si deve ragionare mischiando DB e modello ad oggetti
MauriD [MVP SQL Server] says:
i tre punti per cui a me non piacciono gli orim sono questi:
janky says:
zzZZZZZ
MauriD [MVP SQL Server] says:
1) necessitano di un file di configurazione o della decorazione delle classi tramite attributi. Questo aggiunge uno strato di complessità al sistema
MauriD [MVP SQL Server] says:
dai janky poi ti lascio la parola come porta a porta..tu fai Prodi?
MauriD [MVP SQL Server] says:
janky says:
huahua...mitico...vai sono tutto orecchi!
Mario says:
[MauriD] ma stai facendo altre 1000 cose ? o e' messenger lento ?
MauriD [MVP SQL Server] says:
2) generando in automatico il codice SQL non permettono l'ottimizzazione dello stesso (e questo è un grosso problema, in quanto il codice ottimizzato T-SQL può rendere un'applicazione più veloce anche del 300%...lo scrivo: trecento per cento!)
MauriD [MVP SQL Server] says:
no sto scrivendo
janky says:
MauriD [MVP SQL Server] says:
3) non permettono la gestione della sicurezza di accesso ai dati, in quanto si dovrebbe lavoroare direttamente sulle tabelle fisiche e non sulle stored procedure per poter gestire l'accesso ai dati stessi da parte degli utenti
MarcoDes says:
[Davide] ti faccio una domanda... quando parlo di ORM, parlo di persistenza, di CRUD... una insert, una update, una delete, and so on... cosa c'è da ottimizzare in una UPDATE
MauriD [MVP SQL Server] says:
ok sparate pure sul pianista
MauriD [MVP SQL Server] says:
yup si potrebbe pensare che in effetti una semplice persistenza non abbia bisogno di ottimizzazione
janky says:
ok senza sparare dai...
MauriD [MVP SQL Server] says:
grazie eheh
janky says:
posso dire la mia!
janky says:
posso dire?
luke says:
[MauriD] il punto 2 è quello che più spesso mi fa venire il dubbio se è giusto utilizzare NH
Giangi says:
[janky]vuoi mica dire qualcosa?
Michele says:
[Davide] che strategia useresti allora per passare i dati al domain modell e poi magari ad un client attraverso un servizio?
luke says:
[Tutti] il fatto è che con NH non sono mai certo che stia utilizzando gli indici che creo
MauriD [MVP SQL Server] says:
dicevo, però un db ha una vita mediamento MOLTO più lunga di un'app e quello che oggi è un "semplice" update può diventare qualcosa di molto ma molto più complesso nel giro di breve tempo
janky says:
bah...sparo qualche punto anche io...ma non ce li avevo messi in fila come te davide
janky says:
janky says:
se il mapping introduce complessita da un lato
ema says:
[luke, MauriD] Anche a me, ma: usando accuratamente i metodi di caricamento dei dati (con appositi filtri, ecc....) e usando bene il mapping le performance sono comunque "buone" per un utente...sinceramente nella buona parte delle applicazioni non lo vedo un grosso problema
janky says:
assicura astrazione, dal db, dal dialetto e scrivi quintali di righe in meno...quindi il discorso della complessità...non so non è importante IMHO
Giangi says:
[MauriD] ruguardo il punto 2. Visto che gli orm velocizzano molto lo sviluppo di un data layer non conviene partire con quello ed eventualmente, se si riscontrano dei colli di bottiglia, ottimizzare le query e passare ad un DL puro?
MauriD [MVP SQL Server] says:
[Miky] creo un data access layer personalizzato...se l'accesso al db è solo per pattern CRUD e quindi solo per la persistenza la creazione di "x" stored procedure porta via davvero poco tempo, rispetto al tempo totale di sviluppo di un app
MauriD [MVP SQL Server] says:
ema: io sto generalizzando
ema says:
[MauriD] sisi ok...anche io ...in generale non è un grosso problema
luke says:
[Tutti] ecco l'eterna lotta tra la mi avversione per le SP e la paura di leggere tabelle senza utilizzare gli indici ottimizzati
MauriD [MVP SQL Server] says:
ovviamente per applicazioni piccole (e con una vita breve)se gia conosci NH sei facilitato...io in effetti sto pensado applicazioni di una certa dimensione...gestionali piuttosto che intranet piuttosto che sistemi con una vita medio/lunga
MauriD [MVP SQL Server] says:
Luca il problema è corretto
janky says:
[Davide] ma è proprio nelle applicazioni medio lunghe che ti viene in aiuto un Domain Model e quindi per necessità un ORM
MarcoDes says:
[Davide, ema] ma in fase di fetching l'uso delle storeproc abbinate ad un modello di dominio object oriented non introduce una rigidità troppo elevata
MauriD [MVP SQL Server] says:
è per questo che - anche se ho provato con tutte le mie forze - non riesco proprio ad utilizzare NH
Mario says:
[tutti] ragazzi io sono cotto la chat e' molto interessante ma veramente sono stanco. spero ci saranno altre occasioni come questa. saluti a tutti in particolare a janky per le sue risposte
janky says:
[mario] ma di che! un saluto!
Marco says:
ciao [Mario]
ema says:
[Mario] ciao
luke says:
ciao
Michele says:
ciao
Mario has left the conversation.
janky says:
[Davide] dicevo..è proprio nelle applicazioni medio lunghe che ti viene in aiuto un Domain Model e quindi per necessità un ORM
MauriD [MVP SQL Server] says:
Janky: il Domain Model non si discute, of course. Il problema è "solo" la persistenza...io preferisco farla a mano, anche a costo di metterci un pò di più, perchè cosi ho il controllo totale sulla metodologia di accesso ai dati, che può cosi essere notevolmente ottimizzata a messa in sicurezza senza dover agire sull'applciazione...dopotutto un db ha le sue esigenza
ema says:
[MauriD] il mio pov è questo: senza un orm la gestione di certe problematiche legate alla persistenza è troppo complessa, quindi pago un prezzo (performance, uso del mapping, ecc...) ma sono certo di riuscire ad avere un domain model fatto bene e facile da mantenere
Michele says:
[Davide] ma il Mapping allora?
janky says:
[Davide] ma hai beccato il punto...io sono proprio daccordo sulle esigenze del db...ma qualcuno di voi ha mai provato a scrivere un DAO per un oggetto che ha due o più reference, con due o più collezioni?
MauriD [MVP SQL Server] says:
janky: yup
MauriD [MVP SQL Server] says:
io
MauriD [MVP SQL Server] says:
luke says:
casino
janky says:
[Davide] il problema si evidenza subito negli oggetti rappresentati da grafi mediamente complessi...
ema says:
[Janky, tutti] altra domanda: il domain model non deve avere un riferimento al layer di persistenza, vero? In nessun caso?
MarcoDes says:
[Davide] e come ti regoli, ad esempio, per gestire la navigazione del grafo
janky says:
[Davide] non metto in dubbio che tu abbia modellato bene...ma sei d'accordo con me che gestire la persistenza transitiva di un grafo non è roba da poco?
MarcoDes says:
[ema] no, è per questo che, ad esempio, preferisco i mapping all'uso di attributes
janky says:
[Davide] Eppure un giorno io e te faremo una sessione assieme ME LO SENTO!
fiorerosalba@tiscali.it (E-mail Address Not Verified) has left the conversation.
MauriD [MVP SQL Server] says:
esatto...è propro per quello che prefeisco fare le cose a mano. più il domain model è complesso (e più è complesso il db dato che di fatto modellano in modi diversi le stesse entità, o quasi) più è pericoloso lasciare fare ad un ORM un lavoro automatico che necessarimente non riesci ad utilizzare tutti i "trucchetti" (sarebbe meglio dire esperienza) che invece uno sviluppatore può utilizzare...
imperugo @Milan has been added to the conversation.
ema says:
[MarcoDes] concordo...ma mi pareva di aver visto nella sessione di Janky un diagramma con un link dal domain model verso lo strato di NH...forse mi sbaglio
MauriD [MVP SQL Server] says:
[janky] spero _davvero_ presto...non sono CONTRO gli ORM per definizione...vorrei solo che si capissero e pro ed i contro del loro utilizzo
janky says:
[Davide] in un ORM non c'è niente di automatico....è solamente Configurabile.
imperugo @Milan says:
hi everybody
MauriD [MVP SQL Server] says:
[janky] si ma fino ad un certo punto....non riuscira mai a scrivere una CTE ricorsiva ad esempio
janky says:
[Davide] occhio attenzione...
janky says:
[Davide] il problema della persistenza è solo una nicchia dell'accesso ai dati
MauriD [MVP SQL Server] says:
oppure ad usare degli hint o a "guidare" SQL all'uso di un indice di copertura
luke says:
[Tutti] giusto per capire qui siamo tutti dev o c'è qualche DBA non dev ?
janky says:
[Davide] allorchè ti dovesse capitare qualcosa che va fuori (un mass update per esempio)
janky says:
[Davide] integri...non c'è niente di male
ema says:
[luke] MauriD è una via di mezzo
fiorerosalba@tiscali.it (E-mail Address Not Verified) has been added to the conversation.
MauriD [MVP SQL Server] says:
[janky] yup concordo...ma io (nella mia esperienza) ho visto che un anno ad es. un query di update era solo una query di update...poi 10 sviluppatori hanno messo mani al db, altre applicazioni sono state scritte...ed il risultato è che soddisfare le nuove esigenze, siccome la query è "cablata" nel codice si ricorre all'uso massiccio di trigger
ema says:
[Davide Janky] secondo me avete ragione entrambi è come mettere un esperto di motori e uno di aereodinamica a progettare una macchina...ognuno ha il suo punto di vista ed entrambi hanno ragione...basta trovare il giusto equilibrio
MauriD [MVP SQL Server] says:
come dicevo prima, inoltre, questo ancora non tocca il problema della sicurezza che pur dovrebbe essere tenuto in seria considerazione
fiorerosalba@tiscali.it (E-mail Address Not Verified) says:
concordo con ema
MauriD [MVP SQL Server] says:
ehehe giusto luke
MauriD [MVP SQL Server] says:
[ema] concordo
MarcoDes says:
[Davide] perché la sicurezza non può essere soddisfatta tramite SOA
ema says:
[Tutti] domanda già fatta prima...nessuno usa altri ORM?
MauriD [MVP SQL Server] says:
[MarcoDes] assolutamente no...e qui uso assolutamente di proposito
MarcoDes says:
[Davide] era una domanda, non una semi-affermazione...
MauriD [MVP SQL Server] says:
ah perfetto
MauriD [MVP SQL Server] says:
scusate, faccio una domanda a tutti, visto che siete la maggior parte dev
MauriD [MVP SQL Server] says:
chi di voi pensa di sapere esattamente cosa sia un database?
janky says:
[davide] sul discorso sicurezza anche sentendo il "guru" Raffaele...sappiamo perfettamente che può essere risolta per via "applicativa"
ema says:
[MauriD] un file ?
MauriD [MVP SQL Server] says:
[janky] la risposta sta nella domanda che ho appena fatto...tra un secondo ti rispondo più in dettaglio
MauriD [MVP SQL Server] says:
EMA!
MauriD [MVP SQL Server] says:
ema says:
[MauriD]
MarcoDes says:
[ema] solitamente più di uno
Giangi says:
[janky] raf però dice anceh che la sicurezza deve essere gestita in tutti i punti della architettura
MauriD [MVP SQL Server] says:
[janky] ah ecco
Giangi says:
altrimenti hai un punto debole
Giangi says:
sensibile ad attacchi
fiorerosalba@tiscali.it (E-mail Address Not Verified) says:
è inutile mettere una serratura ad una porta aperta
luke says:
[MauriD] un file ad indici con un log di spazzatura ?
ema says:
[MauriD] per come la vedo io il db è uno degli "strati" della mia applicazione con le sue logiche, ecc...
MauriD [MVP SQL Server] says:
...ora vi motivo il discorso della sicurezza....però ancora nessuno ha risposto...deduco che in pochi abbiate visto il mio webcast dedicato agli sviluppatori
luke says:
io l'ho visto =)
MauriD [MVP SQL Server] says:
bravo
janky says:
[davide] io no...
MauriD [MVP SQL Server] says:
ok visto che nessuno si fa avanti vi do la soluzione
Maurizio Tammacco says:
[MauriD] io purtoppo no
fiorerosalba@tiscali.it (E-mail Address Not Verified) says:
dai MauriD
MauriD [MVP SQL Server] says:
un database non è null'altro che un motore di INFERNZA LOGICA....ogni singola tabella è una entita reale (tangibile o meno) ed ogni colonna della tabella è un attributo che descrivere la realta
MauriD [MVP SQL Server] says:
ergo una riga è una "proposizione"...ossia una affermazione vero
MauriD [MVP SQL Server] says:
il database applica dei meccanismi di logica matematica affinche SE TUTTE LE PROPOSIZIONI SONO VERE anche le risposte alla query che derivano i dati da tali proposizioni SONO VERO
Giangi says:
[MauriD] io non sono d'accordo. Una entità logica non può essere descritta completamente con una struttura bidimensionale
MauriD [MVP SQL Server] says:
chi ha detto che una tabella è bidimensionale?
janky says:
[davide] può essere bi-tri o pluridimensionale
janky says:
[davide] MA non sarà MAI un grafo
Giangi says:
[MauriD] a meno di un db ad oggetti, è così
ema says:
[MauriD, Giagi, Tutti] Ragazzi non voglio fare il rompipalle, ma stiamo uscendo un pochettino dal tema
MauriD [MVP SQL Server] says:
inoltre, visto che attualmente siamo cmq ad usare tabelle, è cmq possibile, in quanto ogni "colonna" è una "dimensione" della nostra entita
janky says:
[davide] e sinceramente non so cosa centri tutto questo con gli ORM...pazienda
MauriD [MVP SQL Server] says:
ora ci arrivo
Giangi says:
[ema] però è interessante la visione di davide
MauriD [MVP SQL Server] says:
il discorso è questo:
MauriD [MVP SQL Server] says:
SE un database ci DEVE dare risultati corretti
ema says:
[Giangi] sicuramente si, ma vorrei rimanere sul tema orm
MauriD [MVP SQL Server] says:
(e su questo siamo tutti daccordo)
MauriD [MVP SQL Server] says:
il DB DEVE impedire l'inserimento di dati FALSI nelle proprie tabelle
janky says:
[davide] il che non induce a pensare che non si debbano usare gli ORM....
ema says:
[Janky] con NH, è possibile usare i file hbm in modo che ereditino tra di loro?
MauriD [MVP SQL Server] says:
dato che un DB è utilizzato da PIU applicazioni...l'unico in grado di ASSICURARE che qualsiasi applicazioni NON possa acedere in modo "non corretto" ai dati è il DB STESSO
janky says:
[ema] intendi qualcosa di paragonabile ai contesti di Spring?
MauriD [MVP SQL Server] says:
[janky] no, ma induce a pensare che la sicurezza DEVE essere applicata sul DB in primis....cosa che non si può quindi relegare allo strato applicativo
MauriD [MVP SQL Server] says:
scusate se sono andato un può fuori tema, ma non credo sia possibile parlare di DB (o di oggetti che ci lavorano sopra) se non conosciamo esattamente il loro significato
janky says:
[davide] chi vieta di pensare alla sicurezza su un database ma fatta in modo applicativo?
ema says:
[janky] non conosco i contesti di spring...mi spiego se alcune classi del mio domain model ereditano da BaseClass che ha alcune proprietà che devono essere mappate è inutile che in tutti i file hbm rimappi sempre le stesse prop....
janky says:
[davide] se si esponesse tutto uno strato di servizi basato sul db...che cosa viola le tue regole di inferenza?
MauriD [MVP SQL Server] says:
[janky] il problema è che se ad un db ci accedono più applicazioni, come puoi gestire la sicurezza di TUTTE le applicazioni in un solo punto? a meno che non crei uno strato di accesso al DB che sia condiviso la vedo dura
janky says:
[davide] non FARE le regole e anche le APPLICAZIONI....
janky says:
[davide] ci sono database per N applicazioni...database per una singola applicazione...database per N applicazioni con strato di servizi
MauriD [MVP SQL Server] says:
[janky] nessuna...il problema è che, attualmente, non è possibile pensare - secondo me - di creare un'unico strato di accesso...
janky says:
[davide] è inutile fare di tutto un facio
janky says:
[davide] stiamo parlando in modo troppo generico
janky says:
[davide] senza nessuna base....la frase "non è possibile fare secondo me uno strato generico" è troppo vaga
MarcoDes says:
[ema] AFAIK no
janky says:
[davide] ergo puoi farlo o non farlo a secondo dei contesti
MauriD [MVP SQL Server] says:
[janky] vero...però infatti ho detto che stavo generalizzando....ovvio che per una applicazione che usa un DB solo suo puoi fare quasi quello che vuoi...il problema è sempre lo stesso: quanto se sicuro che tale DB non sara mai oggetto di reportstinca in futuro? o di integrazione con altri sistemi?
ema says:
[tutti] mai nessuno di voi ha provato a scriversi una sorsa di ORM? (io si )
Michele says:
io ho provato in passato
ema says:
[MarcoDes] infatti sospettavo
janky says:
[ema] io anche, fu il periodo quando impazziii...
Giangi says:
[ema] io anche
MarcoDes says:
[ema] e quante difficoltà hai incontrato
MauriD [MVP SQL Server] says:
io quasi
MarcoDes says:
[ema] perché quando l'ho fatto io sono impazzito
Michele says:
[tutti] tante difficolta' chiaramente
Giangi says:
[ema] però ero più orientato ai generatori di codice piuttosto che gli orm
janky says:
[davide] capisco che tu prima abbia generalizzato...ma proprio per quello devi parlare di "casi" e non di "regole"
ema says:
[MarcoDes] principalmente sulle query con le join...ma tieni conto che si tratta di una cosa molto rudimentale (quando l'ho scritto, parecchi anni fa, non sapevo neppure che fosse un ORM...era solo un modo per evitare di scrivere comandi SQL)...sono anni che non lo uso
janky says:
[davide] sai perfettamente che ci sono al mondo (anche non mie e di raf applicazioni che gestiscono la sicurezza in modo applicativo
luke says:
[Giangi] noi utilizziamo sia generatori CASE (generano sia codice che DB) sia NH la differenza è abissale, ma anche i risultati
janky says:
[davide] e tutto fila liscio...perchè sono fatte bene...
ema says:
[Giangi] si interessante sta cosa: anche io mi sono sempre chiesto cosa è meglio, in teoria il problema performance con i generatori dovresti risolverlo!
MarcoDes says:
[ema] ah, k... quindi quando in questo contesto mi parli di ORM in realtà mi stai parlando di quello che fowler chiama Metadata Mapper
MauriD [MVP SQL Server] says:
[janky] si lo so....sono abbastanza sicuro che prima o poi daranno dei problemini....io lo sto vivendo adesso da un cliente dove è arrivata la GdF
ema says:
[luke] differenza abissale in termini di performance? e riuscite a sincronizzare le modifiche al db o al dm in modo indolore ?
Giangi says:
[ema] per questo mi sono sempre piaciuti i generatori di codice. Il problema però è che i generatori di codice hanno senso in casistiche "catalogabili" che fa un a cazzotti con il concetto di domain model
fiorerosalba@tiscali.it (E-mail Address Not Verified) says:
che brutta parola generatori di codice
MauriD [MVP SQL Server] says:
il fatto che la sicurezza fosse stata impostata tramite applciazioni a permesso ad un uente di "smanettare" con i numeri di fattura.....su indicazioni del supporto tecnico del prodotto...il risultato è che ora è un bel casino. Se la sicurezza (e l'integrita) fosse stata gestita a livello di DB il simpatico operatore non avrebbe potuto fare nulla...
janky says:
[davide] mi fa piacere che tu ti "senta" sempre sicuro...anche su applicazioni di cui nn sai neanche l'architettura..
ema says:
[MarcoDes] si e no...aveva parecchie feature carine stile NH, LazyLoad, query language, transazioni,ecc...
MauriD [MVP SQL Server] says:
[janky] non è un problema di conoscere l'architettura..per quanto buona posso essere se non c'è sicurezza a livello di db con SQLCMD ci metto 10 secondi a rovinare un db....
ema says:
[MarcoDes] la cosa brutta e che mi ha spinto ad abbandonare il progetto è che tutte le classi del dm devono ereditare da una classe base
MauriD [MVP SQL Server] says:
il problema è solo questo...ed infatti non critico certo le architettura delle applicazioni
MarcoDes says:
[ema] poi il team di LinQ ti ha rubato l'idea
luke says:
[ema,Giangi] i generatori di codice ti avvisano se stai leggendo una tabella senza avere l'indice adatto ad esempio, oppure ti dice come è meglio leggerla per evitare ridondanze (genera db in terza forma normale, 0 ridondanze)
janky says:
[davide] tu puoi rovinare il db...arrivandoci puoi fare tutto...se non ci arrivi amen
ema says:
[janky Davide] suvvia ragazzi!!! fate i bravi....
Michele says:
[Ema] ho avuto l ostesso problema con una classe base che conteneva troppa logica
janky says:
[ema] maddai! siamo calmissimi, vero davide??
ema says:
[MarcoDes] cacchio è vero...
MauriD [MVP SQL Server] says:
[janky] ma una mministratore di sistema, ad esempio, come fa a "non arrivarci"....non pensare ad attacchi via web...ma a semplici errori umani
MauriD [MVP SQL Server] says:
certo
ema says:
[luke] da quel punto di vista sono meglio....il problema che io ho notato quando li provai era sulla sincronizzazione delle modifiche (lato db o lato oggetti)
luke says:
[ema, Giangi] fa tutto il lavoro sporco, però, almeno quello che utilizziamo (e commercializziamo) noi, essendo multilinguaggio e multi db, sacrifica molto l'interfaccia generata per mantenere compatibilità tra i vari linguaggi
Giangi says:
[ema] le partial class facilitano notevolmente il problema della sincronizzazione del codice generato
MauriD [MVP SQL Server] says:
[Luca] ecco questo è un bel punto di cui parlare...se i db avessore TUTTI i tipi di dati di .NET sarebbe davvero una gran cosa....il che renderebbe quasi inutile l'utilizzo di ORM
janky says:
[davide] ti prego davide! non limitare gli ORM a questo!
MauriD [MVP SQL Server] says:
luke says:
[ema] per la sincronizzazione lato DB, in caso di app mista (CASE/nativo) facciamo fare tutto al CASE (che gener anche i programmi di riorganizzazione del db)
janky says:
[davide] tenere lo stato delle modifiche e gli stati di transienza di un grafo non è una cosa da ORM?
MarcoDes says:
[luke, ema] in ogni modo, una delle features che apprezzo di più di un orm che genera query dinamiche è la flessibilità in fase di fetching: a seconda dei casi posso modificare radicalmente il comportamento e recuperare una entity in join o lazy (rischiando una seconda query, ma magari tentando un hit in cache). Questo non è un vantaggio concreto in termini di performance
ema says:
[Giangi]....giusto è vero
MauriD [MVP SQL Server] says:
[janky] scherzi a parte...perchè dici cosi? a parte il mapping su db un ORM non fa molto di più... o no?
janky says:
[davide] e allora ti sei vinto un premio....
janky says:
[davide] una cena con il sottoscritto...così ti spiego qualcosa sugli ORM che evidentemente non sai!
MauriD [MVP SQL Server] says:
[janky] ottimo
janky says:
[davide] e il buon marco ne stava parlando pochi secondi fa!
ema says:
[MarcoDes] decisamente si...come dicevo prima...talvolta basta una piccola modifica al file di mapping per cambiare di molto le performance di una query!!
MarcoDes says:
[ema] ad esempio con NH posso farlo anche al di fuori del mapping
MauriD [MVP SQL Server] says:
[janky] puoi anticiparmi qualcosa?
janky says:
[davide] con vero piaciere
janky says:
[davide]
MauriD [MVP SQL Server] says:
MarcoDes says:
[ema] posso fetchare il cliente associato alla fattura in lazy mode in un caso, o in join in un altro...
janky says:
[davide] pensa ad un grafo tipico
janky says:
[davide] ordine - dettagli ordine
ema says:
[MarcoDes] cosa intendi con "fuori dal mapping"?
MauriD [MVP SQL Server] says:
[janky] ok
janky says:
[davide] immagina di dover scrivere come avrai sempre fatto
janky says:
[davide] un suo DAO
fiorerosalba@tiscali.it (E-mail Address Not Verified) says:
Ragazzi è stato un piacere, mi spiace che non ho potuto partecipare tanto comunque spero che ci sia una prossima volta
janky says:
[davide] con le sue belle CRUD...magari con stored proc
MauriD [MVP SQL Server] says:
[janky] ok
fiorerosalba@tiscali.it (E-mail Address Not Verified) says:
buona serata a tutti
Michele says:
ciao Rosalbe
Giangi says:
ciao rosalba
MarcoDes says:
[ema] senza modificare il mapping... posso dire che il cliente di default è lazy loaded, ma con una Criteria posso forzarne il fetch eager in un particolare caso
janky says:
[davide] immagina...Ciao Rosalba!
Maurizio Tammacco says:
ciao
Michele says:
Rosalba
ema says:
[Rosalba] ciao Rosalba...buona notte
luke says:
ciao
imperugo @Milan says:
ciauz
janky says:
davide: immagina di restituire al client un oggetto order completamente popolato
fiorerosalba@tiscali.it (E-mail Address Not Verified) has left the conversation.
ema says:
[MarcoDes] sisi...non avevo letto la seconda parte della frase
MauriD [MVP SQL Server] says:
ZZZZzzz
MarcoDes says:
[ema] lo dico soprattutto per gli altri... fetch eager = con un join
MauriD [MVP SQL Server] says:
ok mi sono vendicato
janky says:
davide: il client lo modifica in modo agnostico, aggiunge una riga, ne modifica un'altra, ne cancella un'altra ancora
MauriD [MVP SQL Server] says:
janky: ok
janky says:
davide: il client passa l'oggetto al metodo update del DAO che dovrebbe persistere TUTTO il grafo
janky says:
davide: come fa a sapere quali righe hai cancellato?
janky says:
davide: come fa a sapere quali sono nuove?
MauriD [MVP SQL Server] says:
janky: ok capisco
janky says:
davide: compito di un ORM tipico è risolvere esattamente questa problematica che va sotto il nome di Persistenza transitiva
ema says:
[MarcoDes] BTW, io come dicevo prima il problema performance non lo vedo...basta "tarare" bene le leve e stare attenti a quello che si carica: vedo spesso programmi che mostrano 1000 clienti in una griglia...ma cosa se ne fa l'utente? meglio premettere un filtro e caricare solo quei 10 che soddisfano il criterio.
janky says:
davide: ok...ti puoi scrivere le tue belle collection con gli stati...fai tutto a mano...ma ti assicuto che i problemi son veramente forti
MarcoDes says:
[ema] anche perché... come ho letto tempo fa nel blog di ayende... se parliamo di performance, il modo migliore per guadagnare in performance è non andare sul DB, quindi il problema si sposta sulla costruzione di un sistema di caching evoluto
Giangi says:
[ema] sono pienamente d'accordo con te. Avere uno strumento che ti diminuisce il numero di righe scritte a vantaggi importantissimi
Maurizio Tammacco says:
[MarcoDes] beh, non sempre è possibile
janky says:
davide: ci sei?
Giangi says:
[ema] meno bug, possibilità di concentrarsi sulla logica di business....
MauriD [MVP SQL Server] says:
janky: però: 1) parti dal presupposto di lavorare offline 2) io personalmente mando un XML con queste informazioni ad una stored procedure che mi fa il "servizio" completo, avendo tra l'altro in questo modo la transazione completamente gestita lato server...chje non è poco. Inoltre lavorando non row-by-row ma sull'intero set di dati beneficio enormemente del lavoro svolto dall'algebirzer
MauriD [MVP SQL Server] says:
e dall'optimizer di sql
ema says:
[Maurizio] perchè dici che non è sempre possibile? se parliamo di esportazioni, ecc...ok..ma quelle anche se ci mettono un paio di minuti non succede nulla
janky says:
davide: ottimo....quindi ti fai tutto a manina...come intendevo io...io ce l'ho gratis
imperugo @Milan says:
[Tutti] Ragazzi purtroppo ho un impegno, devo scappre
Ciauz a tutti
luke says:
ciao
Michele says:
ciao
ema says:
[imperugo] ciao!
janky says:
davide: e non è mica da ridere...come fai a decidere se un oggetto è transiente (creato sul CLR) o caricato/sincronizzato sul database?
MarcoDes says:
[Maurizio] a cosa ti riferisci esattamente
imperugo @Milan has left the conversation.
MauriD [MVP SQL Server] says:
[janky] si non l'ho mai nascosto....io non dico che sia "male" non fare le cose a mano...dico che bisogna essere molto coscienti di quello che si perde in termini di possibilità di ottimizzaione, sicurezza e manutenibilità del codice
Maurizio Tammacco says:
[ema] no, mi riferivo al fatto che per guadagnare in performance non bisogna andare sul db ma usare il caching
MauriD [MVP SQL Server] says:
delle query
janky says:
davide: perfetto...sono almeno convinto che tu abbia capito che allora l'ORM non è solo un mapper tra i tipi di .NET
janky says:
davide: perchè oltre questa piccolo esempio ci sono molte altre cose che potrei dirti...
MauriD [MVP SQL Server] says:
janky: non è un problema... io vedo il db come un sistema che offre servizi attraverso delle stored procedure (per quanto riguarda le applicazioni)...ovviamente il codice che metto nelle SP non ha logica di business ma solo logica legata alla gestione dei dati nel db
janky says:
davide: ecco perchè storcevo il naso quando tu dicevi che avendo i tipi in SQL server non servono più gli orm
ema says:
[Janky] possiamo dire che NSK è un esempio reale di un'applicazione che non usa un ORM ?
MauriD [MVP SQL Server] says:
janky: capisco....il fatto che è io non vedo questa cosa che mi hai descritto come un gran punto di forza
janky says:
davide: semplicemente non la vedi perchè non ti sei trovato tante volte dall'altra parte della barricata con 300 classi a risolvere problemi di questo tipo...
MauriD [MVP SQL Server] says:
[ema, Maurizio] il caching è un altro - secondo me - punto poco conosciuto di SQL
janky says:
[ema] è un discorso lungo quello di NSK!
janky says:
[ema] diciamo che ha una architettura ATTA a nascondere un eventuale uso di ORM, il che potrebbe essere un bene...essere ortogonali alle API di terze parti
Maurizio Tammacco says:
[MauriD] ovvero ?
janky says:
[ema] ma ha una debolezza attuale...non è pensata per lavorare seriamente con la persistenza...partendo da un concetto di Domain Model...
janky says:
[ema] o ne tieni conto by design...o te ne accorgi dopo che ti mancano i pezzi!
MauriD [MVP SQL Server] says:
davide: no ti assicuro capisco bene il problema...io sconsiglio sempre di usare ORM perchè sulla lunga distanza secondo me non offrono benefici...però se è necessario tagliare sui tempo di sviluppo posso capire che sembrino ottimi strumenti...perchè nel'immediato diminuiscono il codice da scriviere....
ema says:
[janky] ok che non è ancora maturo...ma è sulla strada per realizzare un'app con un dm senza usare un ORM (leggi: mi scrivo tutto a mano)
MauriD [MVP SQL Server] says:
[ema, Maurizio]...vero però è anche vero che se le query sono fatto bene (no select * o di campi che non servono, clausole where mirate e via dicendo) tutti e dico tutti gli accessi ai dati SQL li fa dalla memoria cache e non dal disco
janky says:
ema: hai ragione...il fatto è che "quella strada" purtroppo non esiste...nel senso che "sappiamo" io e te che non è affrontabile
luke says:
[MauriD] anche in caso di DISTINCT ?
janky says:
ema: è sempre il problema dell'architettura fatta per un demo...che poi non risulta veramente scalabile ad una applicazione vera
MauriD [MVP SQL Server] says:
[Luca] certo...(ovviamente dipende dalla query, clausola where, indici ecc ecc...però in una situazione corretta si)
MarcoDes says:
[ema, janky] una problematica dal pdv architetturale che ho sempre incontrato usando NH è che, per costruzione, andrebbe referenziato a livello di business layer, rischiando così di legare il cuore della propria applicazione a questo framework. Per dirla in parole spicciole, usate direttamente la Session nella logica di business o ha senso wrapparla al fine di disaccoppiare le due class library
Maurizio Tammacco says:
[MauriD] anche in caso di query con UNION, group by ?
MauriD [MVP SQL Server] says:
[ema] il problema del caching, ad esempio, sul web server è che devi sincornizzarti anche quello....ossia una complicazione in più...in realtà se il tempo speso per sviluppare un sistema efficiente di caching fosse speso per scrivere bene db e query non avresti grossi problemi di recupero dei dati
janky says:
marco: dipende tutto dal tipo di applicazione, come ho sempre detto..le astrazioni costano e costano anche parecchio
janky says:
astrarre nel business layer un sistema di persistenza costa un bel po...
MauriD [MVP SQL Server] says:
sottolieno ancora una volta che sto parlando di casi generali.....ovvio che siti molto molto molto affollati invece ne dabbano fare uso
janky says:
bisogna capire se è davvero necessario
ema says:
[MarcoDes] io di solito wrappo il tutto in un layer di accesso ai dati, le classi di business non sanno nulla di nh, cosi come le classi del DM
MauriD [MVP SQL Server] says:
tanto per fare nomi e cognomi...prima di essere libero professionista mi sono occupato dello sviluppo del sito di panasonic italia....milioni di accessi al giorno ed un cms che permette l'aggiornamento del sito in tempo reale
MarcoDes says:
[ema] quindi tu usi la session solo all'interno delle classi del DAL, per capirci
janky says:
ema: è anche il modello consigliato dalle best practices di NH ma
ema says:
[MarcoDes ] si esatto
janky says:
ema: con l'uso di una session a livello di view...altrimenti ti perdi troppo...
janky says:
ema: e puoi comunque "nasconderla" dentro ad un contetto di PersistenceContext
janky says:
ema: che verrà probabilmente replicato anche nell'architettura di Dlinq...
ema says:
[MarcoDes] anche se in questo modo ho molti metodi "dummy" a livello di business che si occupano solo di girare le chiamate al DAL
MarcoDes says:
[ema] era un approccio che ho utilizzato in precedenza, mi ha creato problemi nella fase in cui ero costretto a far condividere a più persistence manager la medesima session
ema says:
[janky] cosa intendi con "l'uso di una session a livello di view"?
MauriD [MVP SQL Server] says:
non c'è stato bisogno di caching...e ottimizzando le query si sono abbattuti i tempi di risposta di SQL cosi tanto che il caching non è più stato necessario....ed come beneificio corollario si è ottenuto che il database è sempre perforamente non solo per le informazioni in cache
MarcoDes says:
[ema] sì infatti
janky says:
ema: la session è un Contesto di Persistenza che deve affiancare le tue entity laddove esse vengano usate
luke says:
[janky] domanda stupida, ma, in un'applicazione è bene usare sempre una sola session ?
janky says:
ema: se le usi in un layer di presentation per il binding potresti aver sempre bisogno di una session per i casi di lazy load
janky says:
ema: come pure nel business layer
janky says:
ema: quindi devi "astrarre" il concetto di PersistentContext e portarlo nei vari livelli
Giangi says:
ragazzi grazie della chiacchierata e buon proseguimento! Alla prossima!
janky says:
luca: dipende dall'applicazione
luke says:
ciao
ema says:
[MauriD] io credo che tutti i dev debbano farsi un bel corso di SQL ...purtroppo per cultura si tente a trascuerare molti degli aspetti di un DBMS cadendo in errore
janky says:
luca: ci sono dei pattern specifici per ogni tipo di applicazione
luke says:
[janky] qual è la principale discriminante ?
janky says:
luca: per esmepio nel web esiste il concetto di session conversazionale
janky says:
luca: adesso ben documentata nella reference
MauriD [MVP SQL Server] says:
[ema] concordo al 100% dico di più anche ogni DBA dovrebbe farsi un corso di sviluppo...cosi l'un altro potranno finalmente capire i reciproci problemi
Maurizio Tammacco says:
[ema] oggigiorno forse sono più i dba che devono farsi un corso di dev
janky says:
luca: ogni request crea una session e la mette nell' HttpContext
ema says:
[janky] infatti il lazy load! La session deve rimanere aperta vero? Perè ora con la versione nuova di NH non ci sono problemi a lasciarla aperta per un "po'"...o sbaglio?
MauriD [MVP SQL Server] says:
[Maurizio]
janky says:
luca: in genere devi tener conto che la session non è thread safe...è li il vero problema
MarcoDes says:
[tutti] chi di voi ha mai usato NH e DomainModel in generale in un progetto winforms
Maurizio Tammacco says:
[MauriD]
Giangi has left the conversation.
ema says:
[MauriD]
MauriD [MVP SQL Server] says:
yup vi devo lasciare anche io che la moglie reclama la connessione ad internet
janky says:
[ema] no! non deve per forza essere aperta
ema says:
[MarcoDes] io lo sto usando per un progetto winform!
janky says:
[ema] per caricare in una seconda tornata un oggetto che è lazy loaded, ti basta una qualsiasi session...
MauriD [MVP SQL Server] says:
cmq vi invito davvero ad approfondire la conosceza dei DB...non tanto solo per le prestazioni ma sopratutto per sicurezza e manutenibilità del sistema
luke says:
[janky] ma in un'applicazione ( win ) utilizzata da decine di utenti in contemporanea, una sessione per ciascuno può portare a problemi ?
ema says:
[janky] mi sa che allora ho capito male io
MauriD [MVP SQL Server] says:
suvvia i DB non sono nulla di brutto...e poi sono gli unici ad evere una base matematica!
janky says:
[ema] l'operazione che devi fare è solo un attach (session.Update() o session.Lock())
MauriD [MVP SQL Server] says:
matematica è bello
MauriD [MVP SQL Server] says:
MarcoDes says:
[ema] allora anche tu avrai accolto quasi come una manna dal cielo la nuova gestione della connessione
janky says:
luca: no! e perchè mai
MauriD [MVP SQL Server] says:
[janky] ci sentiamo presto....se Roberto Messora non ti ha gia contattato
janky says:
luca: considera una sessione come un wrapper ad una connessione al db...
ema says:
[MarcoDes ]...SISI...tra l'altro devo aver letto la notizia proprio dal tuo blog!!
MarcoDes says:
[ema] che finalmente permette di mantenere una session aperta per tutta la durata di vita di una finestra, senza necessariamente occupare risorse
luke says:
[janky] perchè in alcuni casi ho dovuto ricorrere ad una Clear() per "visualizzare" i dati modificati da altri utenti...
janky says:
luca: la risorsa più pesante di una session è proprio la connessione...che cmq viene gestita in pool...quindi non ti cambia la prospettiva...
MauriD [MVP SQL Server] says:
ciao a tutti!
janky says:
Davide vai via?
MarcoDes says:
[davide] ciao, alla prox
Maurizio Tammacco says:
ciao Davide !
janky says:
CiaO!
Michele says:
ciao Davide
MauriD [MVP SQL Server] says:
ehhh purtroppo la moglie reclama
ema says:
[MauriD] ciao davide...grazie per aver partecipato
MauriD [MVP SQL Server] says:
[janky] sei stato contattato da Roberto Messora?
luke says:
[janky] ciao Davide, grazie =) | nonostante non avessi operazioni in 'coda'
MauriD [MVP SQL Server] says:
[ema] di nulla, a risentirci a presto!
janky says:
davide: ehm...no a che riguardo??
MauriD [MVP SQL Server] says:
MauriD [MVP SQL Server] says:
ok allora ci sentiamo in questi giorni via messenger
janky says:
davide: volentieri!
ema says:
[janky] che ci racconti domani su Nh?
MauriD [MVP SQL Server] says:
ciaoooo
MauriD [MVP SQL Server] has left the conversation.
janky says:
ema: vi faccio un anticipo della traccia?
janky says:
ema:
ema says:
[janky] certo...spara
Marco says:
[tutti]: ragazzi, devo andare. Alla prossima chattata, buona notte a tutti!
MarcoDes says:
[Marco] Ciao, alla prox
luke says:
ciao
Maurizio Tammacco says:
ciao
ema says:
[Marco] ciao!!
janky says:
Ciao!
Marco has left the conversation.
janky says:
Presentazione di NH
Perchè un ORM: Domain Model
Visione del Domain Model di esempio
Visione del Database di esempio
Architettura di NH: Cenni
Cenno allo stato di un oggetto: Transient, Persistent, Detached
Reference alle lib, spiegazione delle lib
Costruzione del singleton SessionHelper
janky says:
Costruzione della mappatura di una classe : class, property id
Costruzione della mappatura con NHDomainMapper
Lyfecycle di base di una entity: SaveOrUpdate, Get Visione dell'SQL prodotto
Dynamic Update
Mapping di un Many-to-One Opzioni di fetching e Visione dell'SQL prodotto
janky says:
Collezione Bag (visione delle altre collezioni)
Mapping delle collection di NHibernate nelle collection .NET
Codice di esempio: aggiunta modifica e rimozione di un child e SQL Prodotto
Opzioni di fetching e Visione dell'SQL prodotto
Cenni alle feature più avanzate: Solo definizioni: UoW e TWB, Optimistic Lock, Cache 2nd, Conversation, HQL e Criteria
Binding all'interfaccia: ObjectViews
MarcoDes says:
[tutti] io mi soffermerei su questa riga
Costruzione della mappatura con NHDomainMapper
janky says:
c'è un po di roba...non è per niente avanzato...
.NET Evangelist - Web 2.0 says:
[jakny]: ricorda di darmi il link x il download
janky says:
marco: peccato che non ho ancora la slide di quello
ema says:
[janky] una mega panoramica!
.NET Evangelist - Web 2.0 says:
[janky]mica posso stare alzato alle 3 di notte
Michele says:
si il link anche a me che non posso esserci, grazie
janky says:
ema: e proprio una costruzione passo passo
janky says:
simone: ok!
janky says:
tutti: io fossi in voi seguirei anche (anche in differita) quello sulla DDD...non è proprio ortodosso...
.NET Evangelist - Web 2.0 says:
janky: interessante chat, peccato non aver potuto partecipare attivamente, xe' sono al lavoro
janky says:
tutti: gli ho dato un taglio molto pratico
.NET Evangelist - Web 2.0 says:
janky: link x DDD?
Michele says:
Janky: non ce la faccio peccato
janky says:
simone: te li passo domani tutti e due
.NET Evangelist - Web 2.0 says:
janky: mitico!!!!!!!!!!!!!
Tiziana has been added to the conversation.
janky says:
michele: tanto registrano
Michele says:
si si
.NET Evangelist - Web 2.0 says:
tutti: forse faccio sessione su NH qui in NZ
janky says:
tutti: quello sulla DDD se riesco a stare sveglio stanotte verrà carino
janky says:
tutti: stavo pensando di drogarmi
ema says:
[Janky] è in programma un webcast avanzato su NH...tipo Best practices?
.NET Evangelist - Web 2.0 says:
janky: ma DDD quindi quando e'?
ema says:
[Tutti] (provocazione) Riagganciandoci ai tre punti di MauriD di prima: come usate il database con un ORM. Intendo è solo un file binario o usate le FK, gli indici, le viste, ecc...ecc.....
janky says:
ema: ehm...proprio avanzato no...sai com'è...c'e il corso a marzo! in Objectway!
MarcoDes says:
[ema] non dovrei dirlo, ma c'è ayende che sta organizzando qualcosa di simile
luke says:
ciao a tutti e grazie per la chiacchierata
janky says:
Ciao luca!
ema says:
[MarcoDes] lo so...ho letto il programma!!
MarcoDes says:
[luke] ciao luca
Maurizio Tammacco says:
ciao
janky says:
ah ma c'è anche un nick che finisce con la "A"
luke has left the conversation.
MarcoDes says:
lol
janky says:
Loporchio batti un colpo
Tiziana says:
ciao ragazzi on ho pfatto in tempo ad arrivare prima
Tiziana says:
sorry
janky says:
se scrivo fesserie è perche la gatta mi sta passeggiando sulla tastiera
Michele says:
ciao Tiziana
Tiziana says:
ciao miky
Michele says:
Janky io ho due gatti qui che mi girano attorno
ema says:
[Tiziana] Don't worry...ti sei persa una luuunga conversazione testa a testa da Janky e Davide Mauri
janky says:
non ti preoccupare...ti sei persa solo il monologo di Davide Mauri
Michele says:
hehe
janky says:
miky: anche tu due gatti!?
Tiziana says:
[tutti]: l'importante è che non litighino
Michele says:
si, due maschi
MarcoDes says:
[ema] personalmente cerco di evitare le storeproc per tutto ciò che non rientri nei canoni di un'elaborazione batch
janky says:
ema: cmq...io il db lo uso in modo minimale...le FK le uso..le contraint...le uso ma giusto per ripetizione
MarcoDes says:
[ema] o per la reportistica, ma perché abbiamo team che si occupano specificamente di quello
janky says:
ema: ahh ovvio...le stored devono essere chiaramente motivate...
janky says:
ema: hai centrato...la reportistica è un aspetto complementare alla persistenza...non è detto che sia una roba da NH
MarcoDes says:
[janky] ero io
ema says:
[janky] quindi la validazione, i controlli sull'integrità, sulla lunghezza dei campi, ecc...la fai a livello applicativo...sul db se c'è bene altrimenti bene lo stesso
janky says:
[marco] scusa!
Michele says:
le stored sono motivate purtroppo a volte perche' ci sono dei DBA e bisogna falri lavorare
Michele says:
tipo nel progetto dove sono adesso...
ema says:
[janky] la reportistica è una cosa a parte....di solito non la metto neppure nell'applicazione...ci sono strumenti fatti apposta per quella
janky says:
michele: LOLL
Maurizio Tammacco says:
[Micky] Magari le SP le scrivessero i DBA
MarcoDes says:
[ema] beh io uso integrità, lunghezza dei campi, ecc....
ema says:
[MarcoDes] però prima di sparare i dati al db verifichi che tutto sia corretto?
Michele says:
[maurizio] almeno in questo caso si....sono fortunato
Maurizio Tammacco says:
[Micky]
MarcoDes says:
[ema] certo, c'è un controllo a livello applicativo e su DB
janky says:
[ema] l'altra volta avevo iniziato una discussione con Raf, sul perchè non usare l'integrità refernziale sul db...ma sinceramente poi abbiamo staccato...sono curioso di capire come la pensi...lui non la userebbe
ema says:
[MarcoDes] ok
MarcoDes says:
[janky] questa se non l'avesse detta Raf, l'avrei bollata come esagerazione
janky says:
marcodes: concordo...era così forte che cmq mi sono fermato a riflettere, voglio sentirlo prima...avrà le sue buone ragioni
ema says:
[janky] io la uso ma giusto per avere una sicurezza in +, tutta la parte di validazione la faccio a livello applicativo prima di salvare, ciò che c'è sul db è solo per essere tranquillo quando qualche "esperto" del CED decide di andare sul db con il client SQL per "aggiornare alcuni dati"
janky says:
tutti: ragazzi io purtroppo devo abbandonare
janky says:
tutti: altrimenti domani alla microsoft racconto le barzellette
.NET Evangelist - Web 2.0 says:
tutti: si raga, vi abbandono pure io..... buona nottata a tutti
ema says:
[tutti] direi che comunque è l'ora per tutti.
janky says:
tutti: beh...farei sicuro più figura di raccontare altr...
MarcoDes says:
[tutti] ragazzi, vado anch'io che domani ho la sveglia alle 5.45
Michele says:
ciao tutti ragazzi buona notte
MarcoDes says:
[tutti] ci vediamo alla cena del 26, chi viene
Tiziana says:
[tutti] ciao $ragazzi
Maurizio Tammacco says:
ciao
janky says:
tutti: allora si stacca tutti?
Michele says:
e ragazze scusa Tiziana
.NET Evangelist - Web 2.0 has left the conversation.
Tiziana says:
[miky] no prblem
ema says:
[Tutti] ok...alloraq finiamo qui....grazie a tutti per aver partecipato...se avete altri temi che vi piacerebbe trattare fatemi sapere cosi orgnizziamo la prossima
MarcoDes says:
[tutti] grazie per la serata!!
Michele says:
grazie a tutti
janky says:
grazie a tutti i picciotti!
MarcoDes says:
[tutti] notte
Maurizio Tammacco says:
[tutti] ciao !
Tiziana has left the conversation.