Moet ek begin met behulp van LINQ SQL?

Question

Op die oomblik is ek met behulp van NetTiers om my toegang data laag en diens laag te genereer. Ek het al met behulp van NetTiers vir meer as 2 jaar en het gevind dat dit baie nuttig wees. Op 'n stadium het ek om te kyk na LINQ so my vrae is ...

1. Het iemand anders weg van NetTiers om LINQ SQL?
2. Was hierdie skakel oor 'n goeie of slegte ding?
3. Is daar enigiets wat ek moet bewus wees van?
4. Wil jy hierdie skakel aanbeveel?

Eintlik sou ek enige gedagtes verwelkom .

Answer 1

1. Geen
2. Sien # 1
3. Jy moet oppas vir standaard onttrekking oorhoofse. Ook dit is baie SQL Server gebaseer in dis huidige stand.
4. Is jy met behulp van SQL Server, dan miskien. As jy met behulp van LINQ vir ander dinge nou soos oor XML data (groot), Object data, Datastelle, dan ja jy moet kan oorskakel na 'n eenvormige data sintaksis vir almal van hulle het. Soos lagerdalek genoem as dit nie gebreek nie maak dit reg. Van die vinnige blik op .netTiers Aansoek Raamwerk, sou ek sê as jy reeds 'n belegging by die oplossing blyk dit vir jou veel meer as 'n eenvoudige Data Access Layer gee en jy moet vashou aan dit.

Uit my ervaring LINQ na SQL is 'n goeie oplossing vir klein-medium grootte projekte. Dit is 'n ORM wat 'n goeie manier om produktiwiteit te verbeter. Dit het ook moet gee jy nog 'n laag van abstraksie wat jou sal toelaat om onder uit te verander die laag vir iets anders. Die ontwerper in Visual Studio (en ek belive VS Express ook) is baie maklik en eenvoudig om te gebruik. Dit gee jou die algemene sleep-val en-eiendom gebaseer redigering van die voorwerp afbeeldings.

@ Jason Jackson - Die Designer doen laat jy eienskappe voeg met die hand, maar wat jy nodig het om die spesifieke eienskappe om daardie eiendom spesifiseer, maar jy doen dit een keer, dit kon neem 3 minute langer as die aanvanklike sleep van die tafel in die ontwerper, maar dit is slegs nodig sodra per verandering in die databasis self. Dit is nie veel verskillend van ander Orms, maar jy is korrek dat hulle dit baie makliker kan maak, en vind net die eienskappe wat verander het, of selfs te implementeer 'n soort van refactoring gereedskap vir sodanige behoeftes.

Resources:

• Hoekom gebruik LINQ na SQL?
• Scott Guthrie op LINQ te
• 10 Wenke om jou LINQ na SQL Application Performance
• LINQ Om SQL en Visual Studio 2008 Performance Update
• Performance Vergelykings LINQ na SQL / ADO / C #
• LINQ na SQL 5 Minute Oorsig

Let daarop dat Parallel LINQ word ontwikkel om voorsiening te maak vir 'n groot groter prestasie op multi-core masjiene.

Answer 2

Ek het probeer om Linq gebruik om SQL op 'n klein projek, dink dat ek wou iets wat ek kon vinnig te genereer. Ek het in 'n baie probleme in die ontwerper. Byvoorbeeld, wanneer jy nodig het om 'n kolom byvoeg by 'n tafel wat jy basies moet verwyder en weer by die tafel definisie in die ontwerper. Indien u enige eiendom op die tafel het 'dan moet jy weer ingestel dié eienskappe. Vir my dit regtig vertraag die ontwikkeling proses.

LINQ na SQL self is mooi. Ek het regtig soos die rekbaarheid. As hulle die ontwerper kan verbeter ek kan dit weer te probeer. Ek dink dat die raamwerk sal voordeel trek uit 'n bietjie meer funksies wat gerig is op 'n ontkoppel model soos web ontwikkeling.

Kyk bietjie na Scott Guthrie se LINQ na SQL reeks van blog boodskappe vir 'n paar groot voorbeelde van hoe om dit te gebruik.

Answer 3

NetTiers is baie goed vir die opwekking van 'n swaar en sterk DAL, en ons gebruik dit intern vir kern biblioteke en raamwerke.

As ek dit sien, LINQ (in al sy inkarnasies, maar spesifiek as ek dink jy vra is om SQL) is fantasties vir 'n vinnige toegang tot die inligting, en ons gebruik dit algemeen vir ratser gevalle.

Beide tegnologie is baie onbuigsaam aan verandering sonder wedergeboorte van die kode of dbml laag.

Dit gesê, gebruik behoorlik LINQ 2 SQL is nogal 'n robuuste oplossing, en jy kan selfs begin om dit te gebruik vir toekomstige ontwikkeling te danke aan dit is die gemak van gebruik, maar ek sou nie weggooi jou huidige DAL vir dit - indien dit Is dit nie gebreek ...

Answer 4

My ervaring sê vir my dat die gebruik van deur gebruik te maak van linQ jy kan kry dinge vinniger gedoen, maar die werklike aksies om die databasis is stadiger.

So ... as jy 'n klein databasis, sal ek sê gaan vir dit. Indien nie, sal ek wag vir 'n paar verbeterings voor die verandering

Answer 5

Ek gebruik LINQ na SQL op redelike groot projek nou (ongeveer 150 tafels) en dit werk baie goed vir my. Die laaste ORM Ek gebruik was iBatis en dit het goed gewerk, maar het 'n baie informatieverzameling om jou afbeeldings gedoen. LinQ SQL presteer baie goed vir my en tot dusver was baie maklik om te gebruik uit die boks te wees. Daar is beslis 'n paar verskille wat jy hoef te oorkom in oorgang, maar ek sou aanbeveel dis gebruik.

n kant nota, het ek nog nooit gebruik of lees oor NetTiers so ek sal nie afslag dis doeltreffendheid, maar LINQ na SQL in die algemeen het bewys dat 'n uiters lewensvatbaar ORM wees.

Answer 6

Ons span gebruik om NetTiers gebruik en gevind dat dit nuttig te wees. MAAR ... hoe meer ons dit gebruik, hoe meer ons gevind hoofpyn en pyn punte met dit. Byvoorbeeld, wanneer jy 'n verandering aan die databasis te maak, moet jy weer op te wek die DAL met CodeSmith wat betrokke is:

• re-genererende duisende lyne van kode in 3 aparte projekte
• -re genereer honderde gestoor prosedures

Miskien is daar ander maniere om dit te doen, maar dit is wat ons gehad het om te doen. Die re-gen van die bron-kode is ok, scary, maar ok. Die werklike probleem het met die gestoor prosedures. Dit het nie enige ongebruikte gestoor prosedures skoon, so as jy 'n tafel van jou skedule verwyder en weer gened jou DAL, die gestoor prosedures vir daardie tafel het nie verwyder word. Ook, het hierdie nogal 'n kopseer vir databasis verandering skrifte waar ons moes die ou databasis struktuur te vergelyk met die nuwe een en 'n verandering script om kliënt installasies te werk. Dit script kan loop in die tien duisende van die lyne van SQL-kode, en as daar 'n probleem was die uitvoering van dit wat daar altyd was, dit was nogal 'n pyn om dit op te los.

Toe kom die lig op, NHibernate as 'n ORM. Dit het beslis 'n oprit-up tyd om dit maar dit is die moeite werd. Daar is 'n ton van ondersteuning vir dit, so as daar is iets wat jy gedoen, meer as waarskynlik dit al voorheen gedoen moet. Dit is uiters buigsaam en laat jou toe om elke aspek van dit en dan 'n paar te beheer. Dit is ook besig om makliker en makliker om te gebruik. Vlot Nhibernate is up and coming as 'n goeie manier om ontslae te raak van die xml kartering lêers wat nodig is en NHibernate Profiler is 'n uitstekende koppelvlak om te sien wat aangaan agter die skerms om doeltreffendheid te verhoog en te verwyder ontslag.

Moving van NetTiers om NHibernate het pynlik, maar in 'n goeie manier. Dit het ons gedwing word om te skuif na 'n beter argitektuur en herevalueer funksionele behoeftes. NetTiers verskaf ton van data toegang kode, kry hierdie entiteit deur sy ID-, kry hierdie ander entiteit deur sy vreemde sleutel, kry 'n tlist en Vlist van hierdie en dat, maar die meeste van dit was onnodig en ongebruikte. NHibernate met 'n generiese repository en persoonlike bronne net waar nodig verminderde ton van ongebruikte kode en regtig verhoog leesbaarheid en betroubaarheid.