Strumento ORM - Crossroads?

Question

Ciao mi sembra di essere ad un bivio ORM strumento e vorrei un consiglio di persone che hanno affrontato una sfida simile. In passato ho utilizzato CodeSmith con i modelli NetTiers per generare il mio DAL tutto è stato abbastanza buono, ma ho deciso di abbandonare questo per un motivo o un altro.

Quindi sono a un bivio e ho trovato il seguente: -

1. Ho guardato PLINQO (LINQ to SQL), che sembra fare un grande lavoro ma con Microsoft incerta di LINQ to SQL questo non può essere una buona scelta.
2. LINQ to Entities - questo è ancora nella sua infanzia e posso sbagliarmi, ma la gente si lamenta la pesantezza e come stored procedure
3. Ho guardato NHibernate, questo forse la scelta migliore, ma sembra essere una curva di apprendimento ripida
4. Idem per LLBLGen
5. Subsonic -? Non sono sicuro di questo
6. rimanere con il NetTiers collaudati, dimenticare la pesantezza, dimenticare che si è costretti a utilizzare la libreria aziendale, dimenticare l'SQL dinamico crea, dimenticare che il loro è quasi alcuna attività sui forum, dimenticare questo e usarlo!

Ho già Codesmith e non voglio per l'acquisto di qualsiasi altra cosa, il codice generato deve lavorare in modalità Medium Trust ...

Ci possono essere altri che ho perso. Sto cercando le risposte che spiegano il motivo per cui lo strumento ORM è la pena di guardare.

Grazie Richard

Answer 1

Ho usato .netTiers me l'ultimo progetto. ma su quella che sto lavorando in questo momento stiamo cercando Linq 2 entità. Hai ragione su Linq2EF non essere maturi. Noi cagna su di esso tutto il tempo che è il motivo per cui usiamo modelli T4 che generano codice dal file EDMX. Abbiamo cambiato anche quei modelli così abbiamo Business Objects, interfacce per l'iniezione e DAL + DAO. Siamo felici di come funziona la società. La cosa buona è che possiamo usare LINQ contro Entità.

In caso contrario Vorrei anche suggerire Fluent NHibernate ( link ) a voi. E 'stata una delle cose che abbiamo anche considerato. Ma si dovrà scrivere un sacco di cose per conto proprio. Non è come si è abituati a in .netTiers in cui tutto il codice viene generato per voi.

Da Subsonic 3 ( link ) è solo circa una settimana Io vi proponiamo controlla. Sulla base di quello che ho visto sembra molto promettente. E utilizza T4, in modo da poter tagliare e tagliarla a dadini per soddisfare le tue esigenze.

Answer 2

Ho provato un paio per un paio di settimane e finalmente risolta con NHibernate. E 'molto facile da personalizzare. C'è una curva di apprendimento e ci vuole un po 'di più per impostare che qualcosa di simile LINQ to SQL ma il lato positivo di questo è che non sembra come per magia. Capirai come funziona e sarà in grado di personalizzare esattamente alle proprie esigenze. La comunità è anche molto buono e c'è un sacco di documentazione disponibile. Mi sembra di essere un buon equilibrio tra una moderna ORM (Nessuna generazione di codice, è possibile utilizzare di POCO), e la maturità.

Answer 3

Si potrebbe provare DataObjects.NET. Questo ORM utilizza approccio "Codice-prima", sostiene DB aggiornamento dello schema e LINQ. Controllare questa breve descrizione http://www.x-tensive.com/Products/DO/ .

Answer 4

Credo che i due strumenti ORM più rinomati e forti in questo momento sono NHibernate e LLBLGen Pro .

NHibernate = Molto Domain Driven oriented.

LLBLGen Pro = Dati Driven oriented.

Sono entrambi eccellenti, e per ogni progetto a seconda è la natura uno può essere più appropriato sopra l'altro. Inoltre viene spesso verso il basso per scelta personale e le preferenze o anche la cultura del team di sviluppo.

Come ho detto anche se alla fine, nel complesso sono entrambi eccellenti ed entrambi hanno le loro lievi vantaggi / svantaggi.

Answer 5

Per ragioni per usare un ORM Ecco un link ad un post sul blog di Glenn Block che dice davvero tutto. Per quanto riguarda la mia esperienza, poco più di un anno fa stavo cercando di usare un ORM e ho scelto NHibernate.

Persistenza per me è un problema risolto, al di là di una qualche forma di mappatura dal mio modello di dominio ai miei dati relazionali è qualcosa che non si deve preoccupare più. Ho guardato LINQ to SQL, ma semplicemente non mi ha dato abbastanza controllo su come i dati sono stati mappati i miei oggetti e Entity Framework non era neanche vicino abbastanza maturi per i miei gusti. Un altro importante progetto po 'della mia squadra stavano lavorando su NetTiers utilizzati e CodeSmith e come dici tu, la pesantezza, la generazione di codice (e l'enorme quantità di esso) mi ha fatto sentire un po' quesy. Alla fine, ho scelto NHibernate perché per me, è uno dei ORM più maturi là fuori e si dispone di una funzione che non solo avrebbero sostenuto un modello di oggetti a grana fine, ma che ha costruito in interrogazione strutture ed indirizzi intrinsecamente altri problemi di prestazioni come la cache.

Sì, devo ammettere che la curva di apprendimento è piuttosto ripida, ma se si investe il tempo, i vantaggi che si ottengono da esso sono enormi. I blog di Ayende Rahien e Fabio Maulo sono una miniera di informazioni su NHibernate. C'è qualche supporto LINQ per NHibernate tramite questo LINQ fornitore ma Steve forte sta mettendo insieme le caratteristiche che fornirà il pieno supporto LINQ in NHibernate. Quindi è tutto andare per NHibernate, ma alla fine della giornata, dipende da cosa si sta più bene con.