Quali sono i criteri per la valutazione di un ORM for.NET? [chiuso]

Sto valutando la valutazione degli ORM.

Ho usato SubSonic , Linq-to-SQL ed Entity Framework . Ho un team di sviluppatori che vanno dai giovani agli anziani.

Quali sono i criteri per la valutazione di un ORM for.NET?

È una domanda carica.
Ci sono molti ORM molto validi che affrontano l'argomento con diverse filosofie.
Nessuno è perfetto e tutti tendono a diventare complessi non appena ti allontani dal loro percorso d'oro (e talvolta anche quando ti attieni ad esso).

Cosa dovresti chiederti quando selezioni un ORM:

1. Cosa deve fare per te?
   Se hai già una serie di requisiti per la tua applicazione, allora dovresti selezionare l'ORM che meglio corrisponde a questi piuttosto che un ipotetico "migliore".

2. I tuoi dati sono condivisi o solo locali?
   Gran parte della pelosità in ORM è causata dal modo in cui gestiscono la concorrenza e le modifiche ai dati nel database quando più utenti sono in possesso di una versione degli stessi dati.
   Se il tuo archivio dati è per un singolo utente, la maggior parte degli ORM farà un buon lavoro. Tuttavia, poniti alcune domande difficili in uno scenario multiutente: come viene gestito il blocco? Cosa succede quando cancello un oggetto? In che modo influisce su altri oggetti correlati? L'ORM sta lavorando vicino al metallo del backend o sta memorizzando nella cache molti dati (migliorando le prestazioni a scapito di aumentare il rischio di staleness).

3. ORM è ben adattato per il tuo tipo di applicazione? Un particolare ORM può essere difficile da lavorare (un sacco di sovraccarico di prestazioni, difficile da codificare) se viene utilizzato in un servizio o seduto all'interno di un'app Web. Al contrario, può essere ottimo per le app desktop.

4. Devi rinunciare a miglioramenti specifici del database?
   Gli ORM tendono a utilizzare l'insieme più comune di denominatori di SQL per assicurarsi di funzionare con molti back-end di database diversi.
   Tutti gli ORM comprometteranno le funzionalità disponibili (a meno che non abbiano come target specifico un singolo back-end) ma alcuni ti permetteranno di implementare comportamenti aggiuntivi per sfruttare i miglioramenti specifici disponibili nel back-end scelto.
   Un tipico miglioramento specifico di db è ad esempio le funzionalità di ricerca full-text; assicurati che il tuo ORM ti offra un modo per accedere a queste funzionalità se ne hai bisogno.

5. In che modo ORM gestisce le modifiche nel modello di dati?
   Alcuni possono aggiornare automaticamente il DB entro una certa misura, altri non fanno nulla e dovrai fare tu stesso il lavoro sporco; altri forniscono un framework per la gestione delle modifiche che consente di controllare gli aggiornamenti del database.

6. Ti dispiace accoppiare la tua applicazione agli oggetti ORM o preferisci gestire i POCO e utilizzare un adattatore per la persistenza?
   Il primo è di solito semplice da gestire ma crea dipendenze sui tuoi oggetti dati specifici di ORM ovunque, il secondo è più flessibile, a costo di un po 'più di codice.

7. Avrai mai bisogno di trasferire i tuoi oggetti da remoto?
   Non tutti gli ORM sono uguali quando si tratta di recuperare oggetti da un server remoto, osservare attentamente cosa è possibile o impossibile fare. Alcuni sono efficienti, altri no.

8. C'è qualcuno a cui puoi rivolgerti per chiedere aiuto?
   C'è un buon supporto commerciale? Quanto è grande e attiva la comunità attorno al progetto?
   Quali sono i problemi degli utenti esistenti con il prodotto?
   Ottengono soluzioni rapide?

Alcuni ORM che ho visto:

• XPO
  Dallo sviluppatore Express: è piccolo e semplice, incentrato sul codice. Lo usano per il loro framework applicativo eXpressApp .
• NHibernate
  è gratuito, ma la curva di apprendimento è piuttosto ripida. Molte chicche, ma è difficile trovare ciò che è veramente rilevante a volte in tutta la documentazione frammentata.
• 
  Progetto molto maturo di LLBLGen Pro , non il più semplice ma è stato pensato molto.
• Entity Framework
  GEtting lì. Le ultime versioni sono abbastanza buone e MS sta ascoltando, anche se è ancora un po 'giovane rispetto ad altri ORM più maturi.
• DataObject.Net
  Sembra promettente ma è anche un po 'nuovo per rischiare un progetto importante su di esso IMHO. Abbastanza attivo però.

Ce ne sono molti altri ovviamente.

Puoi dare un'occhiata al controverso sito ORM Battle che elenca alcuni parametri di riferimento delle prestazioni, anche se devi essere consapevole che la velocità pura non è necessariamente il fattore più importante per il tuo progetto e che i produttori del sito Web sono DataObject.Net.

Sto usando NHibernate e l'ho trovato abbastanza buono.

Nel mio caso, collegato a un database MS Sql, ma è possibile connettersi ad altri database.

Non ci vuole molto per iniziare a funzionare - basta mappare il tuo oggetto sul modello - Uso un file XML ma puoi farlo fluentemente nel codice. C'è una grande comunità, e personalmente ho trovato molto utile il lavoro di Ayende : utilizzo NHProf che è uno strumento di profilatura sql.

Uso principalmente le funzioni out of the box: mappatura diretta degli oggetti, ma ho anche usato il linguaggio di query Hibernate, che è abbastanza facile da ottenere.

Purtroppo, nei miei ultimi tre lavori, abbiamo avuto tre ORM coltivati ​​in casa. In ogni caso, per lo più hanno succhiato per vari motivi.

Di recente ho valutato Entity Framework 4 e il suo supporto POCO (una bella spiegazione è qui ) e sono davvero impressionato da quanto bene mi sfugge di mente e mi fa sentire come se stessi programmando di nuovo piuttosto che cercare dati.

Confronto ORM e benchmark su ORMBattle.NET

Mi piace molto Linq a Sql. È semplice e ha un designer decente. Tuttavia, spero di finire la vita a favore del framework Entity. Vorrei poter sfruttare la possibilità di modificare i generatori in modo da poter avere oggetti personalizzati.

Il più grande vantaggio che questi hanno sugli altri (secondo me) è che sono fuori dagli schemi con VS. Anche questo è negativo in quanto sei in balia della SM (vedi Linq a Sql).

[DISCLAIMER: lavoro per DevExpress]

Potete vedere le immagini di applicazioni tipiche create da strutture di applicazioni DevExpress qui . Questa pagina contiene anche una breve recensione dei nostri prodotti. Per informazioni più dettagliate sul perché , ti suggerisco di consultare le rispettive pagine dei prodotti sul nostro sito web.

Per quanto riguarda DevExpress XAF e XPO, ecco una buona spiegazione del perché scegliere i nostri framework applicativi. Inoltre, forniamo supporto e documentazione, che è anche importante e degno di nota. Non esitate a contattarci in caso di domande.

Usiamo NHibernate + Fluent NHibernate, con Linq-to-Sql su piccoli progetti. La ragione di ciò è:

1) (Non la ragione principale) NHibernate sembra avere un fattore di "rispetto" più elevato tra gli sviluppatori (è vero?),

2) Rispetto a linq-to-SQL, nHibernate consente il mapping ORM tra oggetti Db ed entità che non eseguono il mapping da 1 a 1,

3) Non abbiamo ampiamente confrontato nHibernate con Entity Framework 4.0 ma ecco un buon confronto: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate ha una curva di apprendimento piuttosto ripida e le sue mappe XML possono essere piuttosto dettagliate, ma inizia con la documentazione del sito Fluent Nhibernate e procedi indietro.

Non esiste un "migliore" framework ORM perché hanno tutti diverse combinazioni di punti di forza e di debolezza e tende a succedere che se gli sviluppatori scelgono di concentrarsi sul miglioramento di un'area, ci sono altre aree che soffrono a confronto (codice prima vs prima il modello e prima il database).

Ci sono, d'altra parte, un numero di quelli molto buoni, alcuni dei quali si adatteranno meglio alle tue circostanze personali e alla tua filosofia rispetto ad altri.

Modifica: per quel che vale, attualmente sto usando Linq a SQL, principalmente perché è lì anche se in parte perché fa molto bene con il minimo sforzo e probabilmente passerà di nuovo a Entity Framework "perché è lì" (anche se allo stesso modo c'è anche molto su EF4 che è giusto così come alcune cose che non vanno). La preoccupazione, specialmente con quest'ultima, dovrebbe essere rappresentata dalle prestazioni, ma per la maggior parte dei miei casi non si tratta di un grosso problema e la capacità di eseguire Dynamic Data e OData dai modelli (L2S ed EF) ha notevoli vantaggi per me in termini di " "economico" vince.

Vi consiglio di dare un'occhiata a DevExpress XPO . Questo insieme a DevExpress XAF semplificherà la vita di qualsiasi sviluppatore una volta attraversata la sua curva di apprendimento.

Abbiamo avuto fortuna con Entity Framework. La nostra situazione è in qualche modo insolita, tuttavia: eseguiamo la raccolta di dati per il team di reporting, quindi progettano effettivamente il database. Otteniamo il DB e quindi utilizziamo EF per generare da esso le classi di accesso ai dati. Funziona benissimo per noi, ma eseguiamo solo carichi di dati in blocco, quindi non posso garantire quanto bene funzioni in un ambiente più transazionale.

NHibernate (+ FluentNHibernate) sarebbe l'opzione predefinita per me. È molto flessibile, estensibile e robusto. Ha un numero enorme di utenti ed è molto attivo. L'aspetto negativo è la ripida curva di apprendimento.

LightSpeed ​​di MindScape è semplice e intuitivo , ma comunque abbastanza flessibile e capace. Ha una superficie di design come L2S / EF e un'implementazione UnitOfWork.

Bene, non esiste una scelta "migliore", ma direi che il vecchio Linq-SQL normale soddisfa le tue esigenze. Non è un ORM "vero" di per sé, ma è molto leggero e ti dà la flessibilità di scrivere codice senza esserne consapevole, se questo ha senso. Quello che voglio dire è che puoi continuare a scrivere codice normalmente, senza dover essere veramente a conoscenza di Linq oltre ad avere i dbmlfile. Puoi ancora scrivere astrazioni su di esso, usando i modelli di repository o Gateway, e L2S ricopre il ruolo principale di un ORM, che è quello di aggirare l'accoppiamento relazionale oggetto.

Entity Framework è un po 'pesante, e anche se mi sono dilettato un po' con esso è più "in faccia" rispetto a Linq di base a Sql, ma EF è molto più di un vero ORM di Linq. Vorrei esaminare tutti i criteri che stai cercando in un ORM. È solo perché vuoi evitare di dover scrivere SQL grezzo o, peggio ancora, avere centinaia di Stored procedure? Hai bisogno di alcune funzionalità extra che Linq grezzo non è in grado di fornire? Devi rispondere a queste domande, ma in base al tuo breve requisito ("leggero e facile da usare"), penso che Linq sia leggermente più semplice di qualcosa come Subsonic ed è integrato in Visual Studio.

ECO :) È molto più di un ORM e include al contempo macchine a stati e supporti OCL eseguibili (ovvero EAL). Esiste una versione gratuita con una limitazione di 12 classi di domini che penso dovrebbe essere abbastanza ordinata per i piccoli progetti.