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

È una domanda caricata.
Ci sono molte ORM molto buone che si avvicinano all'argomento con filosofie diverse.
Nessuno è perfetto e tutti tendono a diventare complessi non appena si allontanano dal loro percorso dorato (e talvolta anche quando ci si attacca ad esso).

Cosa dovresti porci quando selezioni un ORM:

1. Che cosa deve fare per te?
   Se hai già una serie di requisiti per la tua applicazione, allora dovresti selezionare l'ORM che meglio si abbina a questi piuttosto che a 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 hanno in mano una versione degli stessi dati.
   Se il tuo datastore è per un utente singolo, 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 elimino un oggetto? In che modo influisce su altri oggetti correlati? L'ORM lavora vicino al metallo del back-end o memorizza nella cache molti dati (migliorando le prestazioni a scapito dell'aumento del rischio di stallo).

3. L'ORM è adatto al tuo tipo di applicazione? Un ORM particolare può essere difficile da utilizzare (un sacco di overhead delle prestazioni, difficile da codificare) se è utilizzato in un servizio o seduto all'interno di un'app Web. Al contrario, potrebbe essere ottimo per le app desktop.

4. Devi rinunciare a miglioramenti specifici del database?
   Gli ORM tendono a utilizzare il minimo comune denominatore set di SQL per garantire che funzionino con un sacco di backend di database diversi.
   Tutti gli ORM comprometteranno le funzionalità disponibili (a meno che non mirino specificamente a un singolo back-end) ma alcuni consentiranno di implementare comportamenti aggiuntivi per sfruttare i miglioramenti specifici disponibili nel back-end scelto.
   Un tipico miglioramento db-specifico è ad esempio funzionalità di ricerca full-text; assicurati che il tuo ORM ti fornisca 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 dovrete fare il lavoro sporco da soli; altri forniscono un framework per la gestione delle modifiche che consente di controllare gli aggiornamenti del database.

6. Stai pensando di associare la tua applicazione agli oggetti di ORM o preferisci gestire i POCO e utilizzare un adattatore per la persistenza?
   Il primo è solitamente semplice da gestire, ma crea dipendenze ovunque sugli oggetti dati specifici di ORM, quest'ultimo è più flessibile, al 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 prelevare oggetti da un server remoto, esaminare da vicino ciò che è possibile o impossibile da fare. Alcuni sono efficienti, altri no.

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

Alcuni ORM che ho visto:

• XPO
  Da 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. Un sacco di chicche, ma è difficile trovare ciò che è veramente rilevante a volte in tutta la documentazione frammentata.
• LLBLGen Pro
  progetto molto maturo, non il più semplice ma è stato pensato molto.
• Entity Framework
  Arrivarci. 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 rischiare un progetto importante su di esso IMHO. Abbastanza attivo però.

Naturalmente ce ne sono molti altri.

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

Sto utilizzando 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 tempo per iniziare e funzionare - basta mappare il tuo oggetto al modello - Io uso un file xml ma puoi farlo con fluidità nel codice. C'è una grande comunità, e personalmente ho trovato Ayende's lavorare per essere molto utile - io uso NHProf che è uno strumento di profilazione sql.

Uso principalmente le funzioni out of the box - mappatura degli oggetti retta, ma ho anche usato il linguaggio di interrogazione Hibernate, che è piuttosto facile da ottenere.

Purtroppo, nei miei ultimi tre lavori, avevamo tre ORM nazionali. In ogni caso, per lo più hanno risucchiato per vari motivi.

Di recente ho valutato Entity Framework 4 e il suo supporto POCO (una buona soluzione è here ) e Sono davvero impressionato dal modo in cui rimane fuori dalla mia faccia e mi fa sentire come se stessi programmando di nuovo piuttosto che raccogliere dati.

Confronto ORM e benchmark su ORMBattle.NET

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

Il più grande vantaggio che questi hanno rispetto agli altri (a mio parere) è che sono fuori dagli schemi con VS. Questo è anche un aspetto negativo in quanto sei alla mercé della SM (vedi Linq to Sql).

[DISCLAIMER: lavoro per DevExpress]

È possibile visualizzare schermate di applicazioni tipiche create dai framework di applicazione DevExpress qui . Questa pagina contiene anche una breve recensione dei nostri prodotti. Per informazioni più dettagliate su perché , ti suggerisco di consultare le rispettive pagine dei prodotti sul nostro sito web.

Come per DevExpress XAF e XPO, qui è una buona spiegazione sul perché scegliere i nostri framework applicativi. Inoltre, forniamo supporto e documentazione, che è anche importante e degna di nota. Sentiti libero di contattarci in caso di domande.

Non esiste un "migliore" schema ORM perché hanno tutte diverse combinazioni di punti di forza e di debolezza e tende ad essere il caso che se gli sviluppatori scelgono di concentrarsi sul rendere una zona migliore ci sono altre aree che soffrono in confronto ( codice prima vs primo modello vs primo database).

Ci sono, d'altra parte, molti di quelli migliori, alcuni dei quali saranno più adatti alle circostanze personali e filosofia di altri.

Modifica: per quello che vale, sto attualmente utilizzando Linq to SQL - principalmente perché è lì, anche se in parte perché fa molto bene per il minimo sforzo e probabilmente passerà nuovamente a Entity Framework "perché è lì" (anche se in modo simile c'è anche molto su EF4, giusto così come alcune cose che non vanno bene). La preoccupazione, soprattutto con quest'ultimo, dovrebbe essere la performance, ma per la maggior parte dei miei casi non è un problema enorme e la possibilità di eseguire Dynamic Data e OData dai modelli (L2S e EF) ha notevoli vantaggi per me in termini di " "vittorie economiche.

Ti consiglio di dare un'occhiata a DevExpress XPO . Questo insieme a DevExpress XAF renderà facile la vita a qualsiasi sviluppatore una volta superata la curva di apprendimento.

Abbiamo avuto fortuna con Entity Framework. La nostra situazione è alquanto inusuale, tuttavia - realizziamo la raccolta di dati per il team di reporting, quindi progettano effettivamente il database. Otteniamo il DB e quindi usiamo semplicemente EF per generare le classi di accesso ai dati da esso. Funziona alla grande per noi, ma facciamo solo carichi di dati alla rinfusa, quindi non posso garantire per quanto bene funziona in un ambiente più transazionale.

NHibernate (+ FluentNHibernate) sarebbe l'opzione predefinita per me. È molto flessibile, estensibile e robusto. Ha una grande quantità di utenti ed è mantenuto molto attivamente. Il rovescio della medaglia è la curva di apprendimento ripida.

LightSpeed di MindScape è semplice e facile da usare, ma comunque abbastanza flessibile e capace. Ha una superficie di progettazione come L2S / EF e un'implementazione UnitOfWork.

Beh, non esiste una scelta "migliore", ma direi che il vecchio e regolare Linq to SQL soddisfa le tue esigenze. Non è un "vero" ORM in 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 come al solito, senza dover essere realmente a conoscenza di Linq se non quello di avere i file dbml . Puoi ancora scrivere astrazioni su di esso, usando i modelli di repository o gateway, e L2S svolge il ruolo principale di un ORM, che è quello di aggirare l'errore di relazione oggettuale.

Entity Framework è un po 'pesante, e mentre ho solo dilettato un po' di più è più "in faccia" del semplice Linq to Sql, ma EF è molto più di un vero ORM di Linq. Guarderei tutti i criteri che stai cercando in un ORM. È solo perché vuoi evitare di dover scrivere SQL raw o, peggio, avere centinaia di stored procedure? Avete bisogno di alcune funzionalità extra che Linq to Sql non può 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 pur includendo macchine a stati e OCL eseguibili (vale a dire EAL). Esiste una versione gratuita con una limitazione di 12 classi di dominio che, a mio avviso, dovrebbe essere abbastanza carina per i piccoli progetti.