Domanda

Qual è il consenso su quando utilizzare uno di questi strumenti in contrapposizione all'altro?Trovo Subsonic molto utile in termini di portare a termine le cose rapidamente, ma su progetti di grandi dimensioni tende a non scalare e lega il modello di dominio al modello di database.È qui che entra in gioco Nhibernate poiché ti offre POCO leggeri che non sono correlati al modello del tuo database, ma il tempo di configurazione è molto più lungo.

Nessuna soluzione corretta

Altri suggerimenti

Mi viene posta spesso questa domanda e in realtà dipende da quanto vuoi giocherellare.Non posso dirti quanto siano stati dannosi i commenti di Chris Cyvas sul ridimensionamento RE SubSonic - e da allora ho risposto a questi :(.

Il punto è che, dal punto di vista delle prestazioni, SubSonic scala molto bene.In termini di crescita del progetto, QUALSIASI strumento che utilizzi richiederà la tua attenzione.Anche NHibernate.

Ho scritto un post su come utilizzare il pattern Repository con DI (come faresti con NHIb o qualsiasi altro strumento) con SubSonic 2.1:

http://blog.wekeroad.com/blog/subsonic-writing-deactivated-testable-code-with-subsonic-2-1/

Ho anche scritto un post sulle prestazioni di SubSOnic:

http://blog.wekeroad.com/blog/subsonic-scaling/

Spero che questo ti aiuti.

Consiglierei SubSonic se il tuo progetto funziona con la visualizzazione ActiveRecord che il database è il tuo modello.Avrai una lezione per tavolo e tutto funzionerà magicamente.Ovviamente puoi modificare e sovrascrivere le cose, ma se tu (o il tuo progetto) non siete fondamentalmente d'accordo con l'approccio classe per tabella, darei un'occhiata a NHibernate poiché inizia con l'approccio più complesso (ma più flessibile) di mappare il tuo modello di dominio nel tuo database.

Se stai utilizzando un database relativamente semplice che è sotto il tuo controllo (ad esempio, puoi modificare le colonne senza inviare otto moduli a un comitato di revisione di supervisione della divisione database), ti consiglio di iniziare con SubSonic e passare a NHibernate se SubSonic non lo fa soddisfare le tue esigenze.

Per quello che vale... ho avuto l'opportunità di utilizzare entrambe le tecnologie un po' di più da quando ho posto questa domanda.E devo restare che se queste tecnologie le scegli conta ben poco.Sicuramente NHibernate consente alle tue entità aziendali di essere leggermente meno accoppiate alla struttura del tuo database, ma trovo comunque che ci siano molte occasioni in cui devi ancora piegarti alla volontà del database.

Secondo me l'unico vero modo per separare totalmente il tuo modello di dominio dal modello di database è scriverne uno tuo DTOS (essenzialmente POCO per il trasferimento dei dati), quindi mapparli nuovamente al tuo ORM preferito nel livello dati.Ma nella maggior parte dei casi, questo approccio sarà più complicato che utile.

Leggermente fuori tema, ma con un tono simile.Hai guardato? Castello ActiveRecord è scritto sopra Hibernate ed elimina la necessità di dedicare tempo alla creazione di mapping XML dal codice al database.Come NHibernate puoi strutturare i tuoi oggetti di dominio come desideri e successivamente generare uno schema di database da questa struttura.

Utilizzando ActiveWriter, uno strumento fornito, puoi facilmente mappare dal tuo database agli oggetti del dominio.

Potresti prendere in considerazione l'idea di guardare Fluent NHibernate;rende la gestione di Hibernate un gioco da ragazzi.Non sono sicuro di quanto sarebbe difficile eseguire la transizione di uno schema esistente, ma se stai creando una nuova applicazione è bello definire il modello di dominio e generare il database praticamente in qualsiasi server DB ti venga in mente.Leggendo gli altri commenti qui, penso che Fluent NHibernate porti NHibernate alla pari con SubSonic per facilità di configurazione.

Non posso fare un buon confronto perché non ho ancora utilizzato NHibernate su un progetto, ma ho usato SubSonic e ne sono rimasto molto soddisfatto.Finora non ho incontrato grossi ostacoli durante l'utilizzo.

Guardare questo post da Rob Conery, uno dei creatori di SubSonic.Parla di come disaccoppiare il tuo codice SubSonic dal resto dell'app.Menziona anche il fatto che questa architettura ti consentirebbe di sostituire successivamente SubSonic con qualche altro livello di accesso ai dati come NHibernate o LINQ to SQL.

So di non aver risposto alla tua domanda, ma spero che questo sia ancora d'aiuto.

IO ha scritto un post sul blog recentemente sugli ORM .NET che contengono Subsonic e ActiveRecord.Dalla mia esperienza dipende da cosa sta facendo il progetto, Subsonic funziona molto meglio se provieni da un background SQL ma NHibernate ha di più.ActiveRecord va bene per progetti più piccoli, non sono convinto che sia più veloce per progetti più grandi che attenersi a NHibernate.

Li ho valutati entrambi e credo che non sarebbe giusto consigliarne uno rispetto all'altro senza capire quali siano i propri obiettivi.Nella tua domanda hai indicato bene le differenze e credo che questo debba essere il tuo fattore decisivo.Personalmente li ho usati entrambi e continuerò a usarli entrambi a seconda del progetto.

  • NHibernate è la mia scelta per progetti su larga scala perché utilizza POCO leggeri.Se mai dovessi cambiare il mio ORM "credo", sarebbe molto più facile eseguire il refactoring.
  • SubSonic è la mia scelta quando ho un progetto su scala ridotta.Credo che SubSonic, dal punto di vista delle prestazioni, si adatti bene.Tuttavia mi sento strettamente legato ad esso perché è così impresso nel mio progetto.Nei progetti più piccoli posso ancora cambiarlo perché la base del codice è così piccola e mi aiuta davvero a estrarre il codice come pubblicizzato.

Ancora una volta leggermente fuori tema, ma passo in secondo luogo Castello ActiveRecord - invece di utilizzare il database come modello (approccio subsonico) o passare ore in spaghetti XML (approccio NHibernate), inserisci semplicemente gli attributi nelle classi del modello.

Puoi anche ottenere ActiveRecord generare lo schema del database per te.

Abbiamo utilizzato questo approccio su diversi progetti e i vantaggi sono i seguenti:

  • Percorso di aggiornamento semplice a NHibernate se necessario in futuro
  • Supporto per semplici modelli di ereditarietà - per esempio.Auto -> Veicolo
  • Lo schema che genera è molto probabilmente come lo avresti creato comunque, quindi puoi dedicare più tempo alla creazione dell'app piuttosto che preoccuparti di mantenere sincronizzato il tuo modello/db.

Penso che tu abbia praticamente centrato l'obiettivo.Subsonic genera codice, quindi i tuoi oggetti aziendali rifletteranno la struttura del tuo database.nHibernate utilizza file di mappatura che mappano i tuoi oggetti business al database in modo che i tuoi oggetti possano essere strutturati come preferisci.

Quanto è grande questo progetto?Sarà necessario un supporto a lungo termine?Il rapporto costo-efficacia di Subsonic compenserà eventuali potenziali problemi di ridimensionamento?

Abbiamo avviato il subsonico e ora stiamo cercando di valutare se passare al letargo ora che siamo nei punti dolenti del subsonico.

La nostra altra opzione è creare una via di mezzo in cui utilizziamo subsonico per interrogare e caricare oggetti arbitrari con la loro funzionalità "esegui come elenco digitato" che esegue una mappatura basata sul nome da un'istruzione SQL arbitraria in stile linq.Oppure provare a ricrearne una parte in nhibernate e rifattorizzare il resto.

Quindi dico che il subsonico ha senso nelle piccole app, ma la manutenzione sulle app subsoniche diventa piuttosto complicata, abbiamo momenti particolarmente difficili con codice di convalida sovrapposto ed eventi attivati ​​pre/post nel codice.Per un modello di record attivo, subsonico è sicuramente presente all'80%, ma fa qualcosa in modo instabile e ti impedisce di avere un controllo reale sulla gerarchia di ereditarietà, poiché ogni classe deve ereditare una tabella per tornare a quella tabella.

Considera il tuo team e le dimensioni del progetto quando prendi in considerazione ActiveRecord.

Nella mia esperienza, ActiveRecord è un'astrazione sopra NHibernate che inizia a perdere come un setaccio quando si provano scenari più complicati.

Se hai uno schema da moderatamente a molto complicato o non semplice, resta con NHibernate.Puoi affettarlo e tagliarlo a dadini quasi alla perfezione.

L'altro posto in cui potresti avere problemi è quando hai bisogno di una query moderatamente complicata.ActiveRecord nasconde gran parte dell'implementazione di NHibernate...ma ti servirà per una query complicata, che diventerà molto difficile se non hai completa familiarità con HQL.Fai attenzione che i membri del team non si limitino a hackerare i bordi invece di imparare NHibernate e HQL.

Accetta il disadattamento di impedenza!

controllalo

:)

Oppure no.Se vuoi prestazioni, fallo da solo.Se lo vuoi semplice e veloce, scegli NHibernate e ActiveRecord.Se ti piace fingere di sapere veramente cosa sta succedendo a livello di accesso ai dati, usa NHibernate e siediti con XML tutto il giorno per far funzionare molti a molti...O semplicemente...err..fai da te - ADO.Net FTW!

Credo che dovresti attenersi a quello che puoi utilizzare al meglio.L'obiettivo finale è la produttività e un codice di qualità con buone prestazioni.Se conosci SubSonic dentro e fuori, attieniti ad esso e se conosci NHibernate in modo approfondito attieniti a NHibernate.Questa è una domanda molto soggettiva.Dovresti anche considerare il fatto di ciò in cui i membri del tuo team hanno esperienza.Se sei bravo, sarai in grado di mantenerlo facilmente.

Ho visto grandi progetti utilizzare SubSonic mentre NHibernate è già famoso e ampiamente utilizzato.

La decisione di scegliere ORM no dipendono esclusivamente dall'ORM stesso.

Il consiglio che ho ricevuto sull'argomento è che Subsonic non si adatta a gestire scenari più complessi e quindi se segui questa strada ti ritroverai con un lavoro che tenta di passare a un ORM più avanzato.

Sono quindi più interessato a utilizzare NHibernate per casi complessi, Castle Active Record per casi più semplici e sto tenendo d'occhio Fluent NHibernate che dovrebbe rendere la mappatura di NHibernate molto più semplice (specialmente una volta migliorato il supporto della mappatura basata su convenzione).

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