Salve

sto seguendo in maniera più concreta sul forum vorrei anche inziiare a fare un passo avanti ed usare un orm prima di tutto però

 alcune domande

1)

la mia appliccazione deve cmq essere orm indipendet ? mi date qualche dritta

2)

specifica su Nhibernate:
se deve fare operazion complesse tipo "CALCOLA media entrate /uscite carichi"
quindi non recuperare tabella ma dati elaborati al volo con Nhibernate come faccio ? che approccio si usa ?

 

grazie  

 

rob:

> la mia appliccazione deve cmq essere orm indipendet ?

Non ti seguo: chiedi se puoi usare un O/RM ma avere una applicazione O/RM independent?

> specifica su Nhibernate: se deve fare operazion complesse tipo...

Sei nel forum meno adatto per una domanda del genere. Magari prova su UGIDotNet, c'e' il forum ORM.

-LV

---

Julio Di Egidio
Analyst Programmer
http://julio.diegidio.name

(Peace X Love] = [++1)

Ciao,
cerco di rispondere alle tue domande per quella che è la mia esperienza:

1) Puoi "complicare" sicuramente la tua architettura progettando un DAL che sia indipendente dall'ORM che usi.... ma a che pro? ha un senso?

2) Con NHibernate puoi fare quello che vuoi. Se devi eseguire update massivi, report o elaborazioni di massa, NHibernate non è sicuramente la scelta ideale. Ma se decidi di usare NHIbernate non devi certo usarlo per tutte le tue necessità. Per la persistenza delle tue entità potresti usare NHibernate, per altri tipi di operazioni puoi usare direttamente ADO.NET.

Alessandro

>1) la mia appliccazione deve cmq essere orm indipendet ? mi date qualche dritta

A mio parere, questa domanda la si deve porre solamente in fase realizzativa (cioè il "design" dell'applicazione, non "architettura") ed in questo caso il quesito dovrebbe avere già la risposta a seconda se il prodotto è un pacchetto, se usufruisce di servizi remoti o se ne offre lui stesso, se il (R)DBMS è free o la licenza ha un costo, il numero di dati che transitano tra gli strati dell'applicazione...ect. Ancora più importante c'è la metodologia che si applica (Managers o SuperEntities od altro ancora) che impatta fortemente sulla scelta della strategia della persistenza dei dati. Se non trovi la risposta nello studio architetturale, allora potrebbe essere incompleto.

Ma al brucio mi chiedo: creare lo strato di persistenza dei dati è laborioso e, ORM o no PALLOSO, ha senso lavorare per essere orm indipendent od ha più senso essere RDBMS indipendent? Ossia non è meglio preoccuparmi che la mia applicazione lavori indifferentemente con Oracle, SQL Server, SQL Anywhere, MySQL piuttosto che preoccuparmi che lavori su tutti gli ORM?

>2) specifica su Nhibernate:
>se deve fare operazion complesse tipo "CALCOLA media entrate /uscite carichi"
>quindi non recuperare tabella ma dati elaborati al volo con Nhibernate come faccio ? che approccio si usa ?

Questo è strettamente per la fase realizzativa e comunque come ti han già risposto nel post precedente, nulla vieta di fare ibridi ORM e classi di accesso ai dati costruite da te (non parlo strattamente di ADO.NET perchè sostengo che il disegno architetturale è universale e debba andare bene per qualsiasi ambiente di sviluppo voglia utilizzare).

>grazie  

Ma niente :-)

 

Progettare un DAL ORM indipendent potrebbe essere un po problematico, puoi trovare un esmpio su Northwind starter kit, in quel caso devi creare un tuo Query Model per gestire le query. Puoi quindi adottare un pattern di Repository oppure di Unit Of Work generici, ed usando un motore di inversione di controllo gestire il concetto di generic specialization (http://msdn.microsoft.com/en-us/library/aa973811.aspx) che può essere usato ad esempio per gestire entità particolari. Il porblema è che creare un Query Model complesso non è facile, potresti però usare LINQ, contando sul fatto che Entity Framework e LINQ to SQL (che non è propriamente un ORM) lo supportano e LINQ to NHibernate è prossimo a venire realizzato.
 

In generale l'approccio che preferisco è quello di creare le classi di dominio, e comunque esporre tutto ai "consumatori" con un layer di servizio che implementa il transaction script , in questo caso le operazioni che prevedono update massivi, o in generale un accesso ai dati che con un ORM potrebbe essere non performante o impossibile, puoi semplicemente usare il vecchio ADO.NET, con l'unica accortezza di creare una struttura che ti permetta di usare la stesas transazione tra ORM e ADO.NET. Considera comunque che puoi sempre recuperare dati dal database con le tue stored o con sql custom e lasciare che sia poi l'ORM a reidratare le entità nei casi in cui magari hai una struttura legacy che mal si adatta ad un ORM.

Alk. 

---

--
Non esiste vento favorevole per il marinaio che non sa dove andare. (Seneca)

blog: Alkampfer's place

[Eng] Alkampfer's place

> Progettare un DAL ORM indipendent potrebbe essere un po problematico

Apoteosi.

-LV

---

Julio Di Egidio
Analyst Programmer
http://julio.diegidio.name

(Peace X Love] = [++1)

LudovicoVan:

> Progettare un DAL ORM indipendent potrebbe essere un po problematico

Apoteosi.

Nessuna apoteosi :D, semplicemente una constatazione dei fatti, dato che ogni ORM utilizza modi differenti per esprimere le query. LINQ può essere una buona soluzione, visto che basta fornire un provider e si può interrogare l'ORM in maniera completamente object oriented. Nemmeno LINQ però è la panacea di tutti i mali, visto che comunque spesso ci sono concetti che sono specifici dell'ORM utilizzato. Ad esempio in Entity framework se vuoi usare una strategia di fetching di tipo eager o immediata devi usare un concetto chiamato "Span" tipo in questa query

var query = from d

            in conn.Department.Include("Course")

            where d.Name == "Economics"

            select d;

foreach (Department dep in query) {

Va da se che il metodo Include, del contesto è specifico di EF, per cui progettando un layer DAL indipendente dall'ORM non puoi naturalmente esporre le caratteristiche specifiche di EF e devi quindi utilizzare il minimo set di feature presente tra gli orm che vorresti supportare.

alk. 

---

--
Non esiste vento favorevole per il marinaio che non sa dove andare. (Seneca)

blog: Alkampfer's place

[Eng] Alkampfer's place

asorcinelli:

2) Con NHibernate puoi fare quello che vuoi. Se devi eseguire update massivi, report o elaborazioni di massa, NHibernate non è sicuramente la scelta ideale. Ma se decidi di usare NHIbernate non devi certo usarlo per tutte le tue necessità. Per la persistenza delle tue entità potresti usare NHibernate, per altri tipi di operazioni puoi usare direttamente ADO.NET.

Ok questo mi è chiaro  cercavo di fare domande per caprie meglio quindi per elaborazioni complesse sempre il solito ado.net.... diciamo e per il crud nhibernate può bastare...

esiste qualche tutorial per iniziare ad usare nhibernate e come configurare il progetto dll impostazioni etc ??
 

 

In giro su nhibernate si trova molto materiale, ma il consiglio spassionato è prendere un buon libro come NHibernate in action (dovrebbe essere uscito) altrimenti Java persistence with Hibernate, che va benissimo lo stesso. In questo libro infatti vengono spiegati bene molti concetti importanti di nhibernate e degli orm in generale, inoltre contiene un buon set di esempi di mapping anche avanzati che sicuramente ti torneranno utile.

Una volta che sei padrone delle basi, se hai qualche problema specifico spesso il forum di nhibernate è il posto giusto dove fare le proprie domande ;)

alk. 

---

--
Non esiste vento favorevole per il marinaio che non sa dove andare. (Seneca)

blog: Alkampfer's place

[Eng] Alkampfer's place

Cylon:

>1) la mia appliccazione deve cmq essere orm indipendet ? mi date qualche dritta

A mio parere, questa domanda la si deve porre solamente in fase realizzativa (cioè il "design" dell'applicazione, non "architettura")

 

Io non sono convintissimo però tu sei più "allenato di me" quindi mi fido ;)

Cylon:

Ma al brucio mi chiedo: creare lo strato di persistenza dei dati è laborioso e, ORM o no PALLOSO, ha senso lavorare per essere orm indipendent od ha più senso essere RDBMS indipendent? Ossia non è meglio preoccuparmi che la mia applicazione lavori indifferentemente con Oracle, SQL Server, SQL Anywhere, MySQL piuttosto che preoccuparmi che lavori su tutti gli ORM?

Bè si dettaglio importante  secondo me se per supportare un orm devi scrivere un strato di software...