Newsgroup: it.comp.dotnet
Titolo: [LINQ] Arma a doppio taglio?

Ciao a tutti,
vi espongo brevemente il mio problema. Sto lavorando ad una applicazione 
desktop in WPF, cercando di seguire un approccio "strettamente" DDD. 
Ora, la mia applicazione è una specie di editor di grafi, una specie di 
accrocco per disegnare mappe mentali e robaccia del genere. La 
persistenza del grafo è su file, in una specie di formato XML. La mia 
gerarchia di oggetti ha una radice comune:
interface IGraphObj {
	Guid Id { ... }
	Boolean IsDirty { ... }
	Boolean IsDeleted { ... }
}
class A : IGraphObj { ... }
class B : IGraphObj { ... }
...ecc ecc...
nel business layer ho definito una interfaccia per un eventuale 
repository di IGraphObj e un servizio di business che implementi le 
varie regole di business:
interface IGraphService {
	...blablabla...
	IQueryable<T> Query<T>() where T : IGraphObj;
}
l'implementazione di questo servizio dovrebbe utilizzare un repository 
con dei metodi generici. So far, so good? E invece no! :-( La mia idea 
era infatti quella di avere ad esempio:
class MyGraphService
{
	protected IGraphObjRepository repo;
 
	IQueryable<T> Query<T>() where T : IGraphObj {
		return repo.Query<T>();
	}
}
tuttavia, quando la query viene "materializzata" non ho la garanzia che 
gli oggetti siano sempre gli stessi (ed è necessario visto che il ciclo 
di vita dell'applicazione può essere tecnicamente infinito). Quindi, 
ragionandoci bene, ho due problemi all'apparenza INSORMONTABILI:
1. la necessità di utilizzare LINQ a livello di applicazione su una 
persistenza in XML secondo un formato "custom";
2. la necessità di implementare un identity map e filrare su questa ogni 
query alla materializzazione.
Ok, mi sono spinto troppo in là?
Ho sbagliato completamente approccio?
Devo implementarmi un super-linq-provider a mano?
Qualche consiglio?
Grazie,
Giulio
-- 

 query alla materializzazione.
Ciao Giulio,
forse non ho capito bene ma:
- perchï¿œ vuoi usare linq to xml invece di deserializzare e usare linq 
to object?
- per ddd l'identity devi garantirla a livello di oggetto e mi sembra 
che il guid faccia il suo mestiere. Fammi capire meglio.
Tieni conto che linq2xml necessita di caricare tutto l'xml in memoria 
quindi non hai comportamenti lazy. Se deserializzi occupi certamente 
meno memoria e hai la comoditï¿œ di lavorare sui tuoi oggetti.
Se cerchi il comportamento lazy verso xml (con l'intento di non 
caricare tutto in memoria) allora ti tocca un provider linq che 
peraltro non ï¿œ banale da scrivere perchï¿œ quando fai la query dovrai per 
forza portarti qualcosa in memoria.... e a quel punto ti conviene usare 
un db documentale come ravendb o mongodb.
-- 
Raffaele Rialdi  
http://www.iamraf.net
Weblog: 
http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - 
http://www.ugidotnet.org/

 documentale come ravendb o mongodb.
una alternativa potrebbe essere quella di usare un formato di 
persistenza ultraminimale come protocol buffer o documenti JSON. 
Peraltro la persistenza non è detto che sia su un unico documento XML ma 
potrebbe già dallo stadio iniziale della cosa essere sparpagliata su più 
files. Ma onestamente non so quanto gli accessi a disco possano essere 
addirittura più fastidiosi. :-)
Grazie,
Giulio
p.s. ravendb e mongodb... mai avuto il piacere. :-) Ho giocherellato un 
po' con le API python di CouchDB. Avresti qualche buon punto di 
partenza? Grazie!
-- 

 con le API python di CouchDB. Avresti qualche buon punto di partenza? Grazie!
sulle rispettive home dei progetti trovi download ed esempi.
Io ho giocato di più con mongodb ma ravendb ha dalla sua il fatto di 
essere json-nativo. Entrambi hanno il provider linq.
Su mongodb trovi anche un paio di articoli su msdn magazine.


 ha mai senso tenerli dentro un db (relazionale o documentale che sia)
...quindi per ora si parte con quattro o cinque cartelle su FS e una 
ventina di files xml. Chi vivrà, vedrà. :-)
Ciao e grazie,
Giulio
-- 

 Giulio
Prego, ciao :)


 paradossalmente è la strada più complessa ... in bocca al lupo :)
Lo so, lo so... :-)
Crepi il lupo!
Ciao,
Giulio
-- 

 Crepi il lupo!
:)
ciao!


 Questa è un'analisi che sta a te ...
Le millemila volte sono *decisamente* sparse. :-)
Direi che sono arrivato a una conclusione plausibile: fintantoché le 
dimensioni del grafo mi permettono di tenere tutto in memoria, farò 
così. Altrimenti, si passa alle weakref.
Grazie ancora,
Giulio
-- 

 Giulio
Prego, ciao
