Domanda

Sto cercando di decidere la migliore strategia per accedere al database. Capisco che questa è una domanda generica e non esiste una sola buona risposta, ma fornirò alcune linee guida su ciò che sto cercando. Negli ultimi anni abbiamo utilizzato il nostro sistema di persistenza, che ha funzionato anche se limitato. Tuttavia ha bisogno di alcuni importanti miglioramenti e mi chiedo se dovrei andare in quel modo o utilizzare uno dei framework esistenti. I criteri che sto cercando, in ordine di importanza sono:

  1. Il codice client dovrebbe funzionare con oggetti puliti, larghezza nessuna conoscenza del database. Quando si utilizza il nostro framework personalizzato, il codice client appare come:

    SessionManager session = new SessionManager (); Ordine ordine = session.CreateEntity (); order.Date = DateTime.Now; // Imposta altre proprietà Dettaglio OrderDetail = order.AddOrderDetail (); dettaglio.Prodotto = prodotto; // Altre proprietà

    // Applica tutte le modifiche ora session.commit ();

  2. Dovrebbe essere il più semplice possibile e non "troppo flessibile". Abbiamo bisogno di un solo modo per fare la maggior parte delle cose.

  3. Dovrebbe avere un buon supporto per la programmazione orientata agli oggetti. Dovrebbe gestire le relazioni uno-a-molti e molti-a-molti, dovrebbe gestire l'eredità, il supporto per il caricamento lento.
  4. La configurazione è preferita per essere basata su XML.

Con le mie attuali conoscenze, vedo queste opzioni:

  1. Migliora il nostro quadro attuale - Il problema è che richiede un grande sforzo.
  2. ADO.NET Entity Framework - Non ha una buona comprensione, ma sembra troppo complicato e ha recensioni negative.
  3. LINQ to SQL - Non ha una buona gestione delle pratiche orientate agli oggetti.
  4. nHibernate: sembra una buona opzione, ma alcuni utenti segnalano troppi errori arcaici.
  5. SubSonic: da una breve introduzione, sembra troppo flessibile. Non lo voglio.

Cosa suggerirai?

Modifica

Grazie Craig per la risposta elaborata. Penso che aiuterà di più se fornirò maggiori dettagli sul nostro framework personalizzato. Sto cercando qualcosa di simile. Ecco come funziona il nostro framework personalizzato:

  1. Si basa su DataSet, quindi la prima cosa da fare è configurare Set di dati e scrivere le query necessarie lì.
  2. Si crea un file di configurazione XML che specifica come le tabelle DataSet si associano agli oggetti e specifica anche le associazioni tra loro (supporto per tutti i tipi di associazioni). 3. Uno strumento personalizzato analizza la configurazione XML e genera il codice necessario. 4. Le classi generate ereditano da una classe base comune.

Per essere compatibile con il nostro framework, il database deve soddisfare questi criteri:

  1. Ogni tabella dovrebbe avere una singola colonna come chiave primaria.
  2. Tutte le tabelle devono avere una chiave primaria dello stesso tipo di dati generata su cliente.
  3. Per gestire l'ereditarietà è supportata solo l'ereditarietà di una singola tabella. Anche il file XML, quasi sempre offre un modo unico per ottenere qualcosa.

Ciò che vogliamo supportare ora è:

  • Rimuovi la dipendenza dai DataSet. Il codice SQL dovrebbe essere generato automaticamente ma il framework NON dovrebbe generare lo schema. Voglio controllare manualmente lo schema DB.
  • Supporto più solido per le gerarchie ereditarie.
  • Integrazione opzionale con LINQ.

Spero sia più chiaro ora quello che sto cercando.

È stato utile?

Soluzione

  

Migliora il nostro quadro attuale - Il problema è che ha bisogno di molti sforzi

Nella tua domanda, non hai indicato il motivo per cui dovresti riscrivere la funzionalità che è disponibile da così tanti altri posti. Suggerirei che reinventare un ORM non sia un buon uso del tuo tempo, a meno che tu non abbia esigenze uniche per l'ORM che non hai specificato nella tua domanda.

  

ADO.NET Entity Framework

Stiamo usando Entity Framework nel mondo reale, software di produzione. Complicato? Non più della maggior parte degli altri ORM per quanto posso dire, vale a dire, "abbastanza complicato." Tuttavia, è relativamente nuovo e come tale c'è meno esperienza e documentazione della comunità di qualcosa come NHibernate. Quindi la mancanza di documentazione potrebbe far sembrare più complicato.

Entity Framework e NHibernate adottano approcci nettamente diversi al problema di colmare il divario tra oggetti e relazione. Ne ho scritto molto più in dettaglio in questo post sul blog . Dovresti considerare quale approccio ha più senso per te.

Ci sono stati molti commenti sul Entity Framework, sia positivi che negativi. Alcuni di questi sono ben fondati e alcuni sembrano provenire da persone che stanno spingendo altre soluzioni. Le critiche fondate includono

  • Mancanza di supporto POCO. Questo non è un problema per alcune applicazioni, è un problema per altre. Il supporto POCO verrà probabilmente aggiunto in una versione futura, ma oggi il meglio che Entity Framework può offrire è IPOCO.
  • Un file di mappatura monolitico. Questo non è stato un grosso problema per noi, poiché i nostri metadati non sono in costante evoluzione.

Tuttavia, alcune critiche mi sembrano mancare alla foresta per gli alberi. Cioè, parlano di caratteristiche diverse dalla funzionalità essenziale della mappatura relazionale degli oggetti, che Entity Framework ci ha dimostrato di fare molto bene.

  

LINQ to SQL - Non ha una buona gestione delle pratiche orientate agli oggetti

Sono d'accordo. Inoltre, non mi piace l'attenzione di SQL Server.

  

nHibernate: sembra una buona opzione, ma alcuni utenti segnalano troppi errori arcaici.

Bene, la cosa bella di NHibernate è che c'è una comunità molto vibrante attorno ad essa, e quando incontri quegli errori esoterici (e credimi, l'Entity Framework ha anche la sua parte di errori esoterici; sembra che ci sia il territorio) spesso puoi trovare soluzioni molto facilmente. Detto questo, non ho molta esperienza personale con NHibernate oltre la valutazione che ci ha portato a scegliere Entity Framework, quindi lascerò che altre persone con esperienza più diretta commentino questo.

  

SubSonic: da una breve introduzione, sembra troppo flessibile. Non lo voglio.

SubSonic è, ovviamente, molto più di un semplice ORM e gli utenti di SubSonic hanno la possibilità di scegliere un'implementazione ORM diversa invece di utilizzare ActiveRecord di SubSonic. Come framework per applicazioni web, lo prenderei in considerazione. Tuttavia, la sua funzionalità ORM non è la sua ragion d'essere, e penso che sia ragionevole sospettare che la porzione ORM di SubSonic avrà meno attenzione rispetto ai framework ORM dedicati.

Altri suggerimenti

LLBLGen crea un ottimo strumento ORM che farà quasi tutto ciò di cui hai bisogno.

iBATIS è il mio preferito perché hai un controllo migliore sull'SQL

Developer Express Persistence Objects o XPO come è più noto. Lo uso da 3 anni. Fornisce tutto ciò di cui hai bisogno, tranne che è commerciale e ti leghi con un'altra (singola azienda) per il tuo sviluppo. Oltre a ciò, Developer Express è uno dei migliori fornitori di componenti e framework per la piattaforma .NET.

Un esempio di codice XPO sarebbe: 

using (UnitOfWork uow = new UnitOfWork())
{
  Order order = new Order(uow);
  order.Date = DateTime.Now();
  uow.CommitChanges();
}

Suggerisco di dare un'occhiata al ActiveRecord dal castello Non ho esperienza di produzione con esso, ho appena giocato con la loro app di esempio. Sembra davvero facile lavorare con, ma non lo so abbastanza bene per sapere se soddisfa tutti i tuoi requisiti

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top