agosto 2009 Blog Posts
Bart fa post fiume interessantissimi e tutte le volte che ne produce uno nuovo mi viene male perchè leggerlo e capiro fino in fondo è spesso un delirio… Mi fischiano già le orecchie: oddio un’altro post fiume… Quindi sappiate che se mi maledite vi capisco :-) .m
Nonostante il titolo questo post è uno strascico di quello sulla conversazione di qualche tempo fa. Te l’avevo detto io, te l’avevo detto io, ehehehe ehehehe :-) Facciamo un po’ di storia. C’erano una volta i cursori e i lock pessimistici: poi, forse fortunatamente, il mondo si è evoluto e siamo passati agli scenari disconnessi: In uno scenario disconnesso semplicemente si carica/crea una rappresentazione in memoria dei dati e si lavora su quella rappresentazione invece che direttamente sullo storage. Questo secondo approccio risolve molti problemi, permette scenari di gran lunga...
Trovo che la sintassi di C# accoppiata ad un po’ di sane Fluent Interfaces porti a qualcosa di semplicemente bello, l’eleganza del risultato è una delle cose che mi piacciono sempre molto. var command = DelegateCommand.Create()
.OnCanExecute( o => true )
.OnExecute( o => { } )
.TriggerUsing( PropertyChangedObserver
.Monitor( this )
...
una piacevole chiaccherata via messenger con Marco di Sanctis mi porta verso questo post che probabilmente sarà il primo di una serie, probabilmente. Vediamo di dare un paio di definizioni giusto per inquadrare lo scenario: Database Transaction: è una transazione specificamente sui dati il cui scope è limitato al database/storage, per sua natura deve essere il più “stretta” possibile, dove per stretta intendiamo iniziare il più tardi possibile e terminare il prima possibile; il perchè è evidente: durante una transazione a livello di storage abbiamo, in base al livello di isolamento, fondamentalmente un lock pessimistico sui dati ergo...
Disclaimer(s) :-) Sto studiando quindi prendete tutto molto con le pinze; Sono decisamente allergico al manuale delle istruzioni quindi usate delle pinze belle grosse :-); Detto questo, immaginate di avere il vostro bel dominio siffatto: Il resto per ora è poco importante, il capo dice che in DDD non è buona cosa esporre la Primary Key perchè non è cosa pertinente al dominio ma è un problema dello storage, sono pienamente d’accordo ma è altrettanto vero che è pur sempre un gran comodo averla li...
Agghiacciante… adesso mi sono comperato questo, che non ho ancora iniziato: Che parla della “Commissione Mitrokhin” che è un pezzo della nostra storia di cui non so nulla. .m
…sembra una parolaccia, e per molti versi ritengo che lo sia, ma andiamo con ordine: diciamo che avete il vostro “bel” dominio mappato con il fido Linq to Sql e siete decisamente felici di come funzionano le cose, nonostante gli evidenti limiti di L2S, ma ad un certo punto succede che i requisiti vi impongono di integrare all’interno della vostra applicazione dati che arrivano da una sorgente dati diversa, nello specifico un preistorico database dbase (v.2), che ha il piccolo difetto di non supportare in alcun modo la multiutenza ergo il primo che arriva “locca”...