Subsonic Vs NHibernate

Am bootstrapat cu subsonic și acum încearcă să evalueze dacă vom trece la nhibernate acum că suntem la punctele de durere ale subsonice.

O altă opțiune este aceea de a crea o bază intermediară în care utilizăm subsonic să interogăm și să încarcă obiecte arbitrare cu funcția lor "execute as typed list", care face o mapare bazată pe nume a unei instrucțiuni arbitrare linq sql. Sau să încercăm să recreăm o parte din ea în nhibernate și refactorul restul.

Așa că eu spun că subsonic are sens în aplicațiile mici, dar întreținerea aplicațiilor subsonești devine destul de păros, avem vremuri deosebit de grele cu codul de validare care se suprapune și evenimentele pre / post declanșate de cod. Pentru un model de înregistrare activă, subsonica este cu siguranță 80% acolo, dar face ceva într-un mod ciudat și te oprește de a avea un control real asupra ierarhiei dvs. de moștenire, deoarece fiecare clasă trebuie să moștenească o masă pentru a se întoarce la masa respectivă.

Cred că l-ai făcut cu greu. Subsonic generează cod, astfel încât obiectele afacerii dvs. vor reflecta structura bazei dvs. de date. nHibernate folosește fișiere de cartografiere care cartografiază obiectele afacerii dvs. în baza de date, astfel încât obiectele dvs. pot fi structurate oricum doriți.

Cât de mare este un proiect? Va fi nevoie de sprijin pe termen lung? Eficiența costurilor Subsonic va compensa eventualele probleme de scalare?

Ușor de pe subiect, dar într-o vină similară. Te-ai uitat la Castle ActiveRecord este scris în partea de sus a NHibernate și elimină necesitatea de a petrece timpul creând mapări xml de la cod la baza de date. La fel ca NHibernate, puteți structura obiectele de domeniu după cum doriți și puteți genera mai târziu o schemă de bază de date din această structură.

Folosind ActiveWriter , un instrument contribuit, puteți hărți cu ușurință de la baza de date la obiecte de domeniu.

Pentru ce merită ... am avut ocazia să folosesc ambele tehnologii destul de abit mai mult de când am pus această întrebare. Și trebuie să rămân, dacă tehnologiile pe care le alegeți foarte puțin. Sigur, NHibernate permite entităților dvs. de afaceri să fie puțin mai puțin cuplate cu structura bazei dvs. de date, dar încă mai constat că există multe ocazii în care încă mai trebuie să vă îndoiți de voința bazei de date.

În opinia mea, singura modalitate adevărată de a vă separa complet modelul dvs. de domeniu din modelul bazei dvs. de date este să scrieți propriul DTOS (în mod esențial, POCO pentru transmiterea datelor în jurul lor) și apoi să le redimensionați în ORM aleasă în stratul de date. Dar, în majoritatea cazurilor, această abordare mă va face mai multă hassle decât valoarea ei.

Aș recomanda SubSonic dacă proiectul dvs. funcționează cu vizualizarea ActiveRecord că baza de date este modelul dvs. Veți obține o clasă pe masă și totul funcționează în mod magic. Desigur, puteți schimba lucrurile, dar dacă tu (sau proiectul tău) nu sunteți de acord cu abordarea clasă pe masă, m-aș uita la NHibernate, deoarece începe cu abordarea mai complexă (dar mai flexibilă) a cartografierii domeniu în baza de date.

Dacă utilizați o bază de date relativ simplă, care este sub controlul dvs. (ca în, puteți modifica coloanele fără a trimite opt formulare la o bordeliere de revizuire a diviziunii bazei de date), aș recomanda să începeți cu SubSonic și să vă deplasați la NHibernate dacă SubSonic nu satisface nevoile tale.

Am am scris un post blog recent despre ORM-urile .NET care au Subsonic în el și ActiveRecord. Din experiența mea depinde de ceea ce face proiectul, Subsonic funcționează mult mai bine dacă veniți dintr-un fundal SQL, dar NHibernate are mai mult de atât. ActiveRecord este bun pentru proiecte mai mici, nu sunt convins că este mai rapid pentru proiecte mai mari decât lipirea la NHibernate.

Cred că ar trebui să vă lipiți de unul pe care îl puteți folosi cel mai bine. Scopul final este productivitatea și codul de bună performanță. Daca stii ca SubSonic intra si iesi afara, atunci stai la el si daca stii NHibernate in profunzime se lipeste de NHibernate. Aceasta este o întrebare foarte subiectivă. De asemenea, trebuie să aveți în vedere faptul că ceea ce echipa dvs. de membru are expertiză cu. Dacă sunteți buni la ea, veți fi în măsură să o întrețineți cu ușurință.

Am văzut mari proiecte folosind SubSonic, în timp ce NHibernate este deja cunoscut și folosit pe scară largă.

Decizia de alegere a ORM nu este    depinde numai de ORM în sine.

Am evaluat ambele și cred că nu ar fi corect să vă recomandăm una peste cealaltă, fără a înțelege care sunt obiectivele dvs. În întrebarea dvs. ați declarat bine diferențele și cred că trebuie să fie factorul dvs. decisiv. Personal am folosit ambele și va continua să utilizeze ambele în funcție de proiect.

• NHibernate este alegerea mea pentru proiectele pe scară largă, pentru că utilizează POCO-urile ușoare. Dacă aș renunța vreodată la ORM-ul "cred", acest lucru ar fi mult mai ușor pentru refactor.
• SubSonic este alegerea mea atunci când am un proiect de scară mai mică. Cred că performanța înțeleaptă subSonic scară bine. Cu toate acestea, mă simt strâns legată de ea, deoarece este atât de gravată în proiectul meu. În proiectul mai mic, pot să îl dezactivez, pentru că baza de cod este atât de mică și mă ajută într-adevăr să scot codul ca anunțat.

Nu pot da o bună comparație, deoarece nu am folosit încă NHibernate pentru un proiect, dar am folosit SubSonic și am fost foarte mulțumit de el. Până în prezent, nu am lovit nici un obstacol major atunci când o folosesc.

Consultați această postare de la Rob Conery, unul dintre creatorii SubSonic. El vorbește despre cum să vă deconectați codul SubSonic de restul aplicației. El chiar menționează faptul că această arhitectură vă va permite să schimbați ulterior SubSonic pentru un alt strat de acces la date, cum ar fi NHibernate sau LINQ to SQL.

Știu că nu am răspuns la întrebarea dvs., dar sper că acest lucru încă ajută.

Din nou puțin sub topic, dar voi second Castle ActiveRecord - mai degrabă decât să utilizați baze de date ca modelul dvs. (abordare subzonă) sau ore petrecute în spaghete xml (abordare NHibernate), pur și simplu plasați atribute pe clasele de model.

Puteți obține chiar și ActiveRecord la generați schema bazei de date Pentru dumneavoastră.

Am folosit această abordare pe câteva proiecte acum și beneficiile sunt după cum urmează:

• Easy upgrade path to NHibernate if required in the future
• Support for simple inheritance models - eg. Car -> Vehicle
• The schema it generates is most likely how you would have created it anyway, so you can spend more time building the app rather than worrying about keeping your model/db in sync.

Luați în considerare echipa și dimensiunea proiectului atunci când luați în considerare ActiveRecord.

În experiența mea, ActiveRecord este o abstracție pe partea de sus a NHibernate care începe să scurgă ca o sită atunci când încearcă scenarii mai complicate.

Dacă aveți o schemă moderată până la greu complicată sau non-simplă, rămâneți cu NHibernate. Poți să taie și să o dai la perfecțiune.

Celălalt loc în care s-ar putea să intri în probleme este când ai nevoie de o interogare moderată complicată. ActiveRecord ascunde o mulțime de implementare a lui NHibernate ... dar veți avea nevoie de o interogare complicată, care va deveni foarte dificilă dacă nu sunteți complet familiarizat cu HQL. Fiți atent membrii echipei nu doar hack departe la margini în loc de a învăța NHibernate și HQL.

Sfatul pe care l-am obisnuit pe acest subiect este ca Subsonic nu se scalifica pana sa se ocupe de scenarii mai complexe, asa ca daca coborati pe acel drum veti incheia un job incercand sa schimbati un ORM mai avansat.

Prin urmare, sunt mai interesat să folosesc NHibernate pentru cazuri complexe, Castle Active Record pentru cazuri mai simple și să păstrez un ochi pe Fluierul NHibernate, care ar trebui să facă mult mai ușor maparea NHibernate (mai ales după îmbunătățirea suportului de cartografiere bazat pe convenție).

Îmbrățișează impedanța de nepotrivire!

verificați acest lucru

:)

Sau nu. Dacă doriți performanță, faceți-o singură. Dacă doriți să fie rapid și ușor, mergeți cu NHibernate și ActiveRecord. Dacă vă place să pretindeți că știți de fapt ce se întâmplă la nivelul accesului la date, utilizați NHibernate și stați cu xml pe toată durata zilei pentru a obține mulți la mulți ... sau doar ... err .. face-l singur - ADO.Net FTW!