webForumDet fria alternativet

Är LINQ bra?

.NETur .NET

12 svar · 956 visningar · startad av inspiro

Medlem sedan sep. 2005673 inlägg
Frågan#1

Någon som har kört LINQ i något projekt? Tycker ni det har fungerat bra? Jag bygger många mindre applikationer och skulle behöva en snabbt och smidigt dal så man får upp utvecklingshastigheten lite.

Medlem sedan jan. 20022 440 inlägg
#2

Är inte så förtjust i LiNQ, har behövt mer än vad som erbjuds. Nu ska de dessutom lägga ner LiNQ to SQL så om det är något sådant du letar efter kan jag varmt rekommendera Entity Framework med LiNQ to Entities för att ställa frågorna.

Medlem sedan dec. 19996 522 inlägg
#3

Catz, vad saknar du i Linq?

De ska inte direkt lägga ner Linq2Sql, men först och främst fokusera på EF. Angående EF så fick de designförslagen för v2 (http://blogs.msdn.com/efdesign/archive/2008/11/20/n-tier-improvements-for-entity-framework.aspx) mig att sätta kaffet i vrångstrupen, hur fan tänkte de där.

Ayende sammanfattar det rätt bra tycker jag, http://ayende.com/Blog/archive/2008/11/21/stealing-from-your-client.aspx

Vill du ha ett snabbt framtagen dataaccess så kan du ju antingen köra linq2sql, active record från castle windsor, eller subsonic som jag personligen tycker ser trevlig ut (nya versionen)

Medlem sedan nov. 20014 054 inlägg
#4

inspiro skrev:

Någon som har kört LINQ i något projekt? Tycker ni det har fungerat bra? Jag bygger många mindre applikationer och skulle behöva en snabbt och smidigt dal så man får upp utvecklingshastigheten lite.

Vi kör Linq i alla skarpa projekt. Har inget direkt negativt att säga om Linq.

Men får uttrycka mig om det senare..

Medlem sedan nov. 20014 054 inlägg
#5

Iofs det jag kan säga lite negativt om Linq är att ex

Dim query = From u In DbContext.Users Where u.UserName = userName And u.Password.Equals(password, StringComparison.CurrentCulture) _
		And u.IsDeleted = False And u.Inactive = False Select u

Funkar inte, i och med att Linq speciellt när man talar om linq-to-sql så måste det vara fullt översättningsbart till SQL... vilket det inte är i detta fall.. utan får först bara köra på u.Password = password,

Sen om man fått matchningar på det, så får man göra på den nya queryn ... vilket jag tycker är lite omständigt.. önskade att Linq att fixat det by magic. hehe

Medlem sedan jan. 20022 440 inlägg
#6

erka skrev:

Angående EF så fick de designförslagen för v2 (http://blogs.msdn.com/efdesign/archive/2008/11/20/n-tier-improvements-for-entity-framework.aspx) mig att sätta kaffet i vrångstrupen, hur fan tänkte de där.

Ayende sammanfattar det rätt bra tycker jag, http://ayende.com/Blog/archive/2008/11/21/stealing-from-your-client.aspx

Problemet med ChangeTracking i EF är klart ett problem om du kör en Thin, eller Smart Client.

Håller med om att de inte når hela vägen fram i version 2 men det hade jag å andra sidan räknat med.

erka skrev:

Catz, vad saknar du i Linq?

entity sql (behöver det ibland) och bättre möjligheter att skräddarsy min model. Nu är det iofs jäkligt länge sedan jag använde Linq :)

Medlem sedan maj 20012 812 inlägg
#7

Största nackdelen med LINQ To SQL är helt klart de obefintliga möjligheter till "egar loading". Att ha ett objekt som innehåller andra objekt och försöka få LINQToSQL att fylla alla dessa objekt direkt utan femtiåttamiljoner sqlanrop är helt omöjligt...

- M

Medlem sedan aug. 20003 575 inlägg
#8

Jag tycker att tekniken är bra, dock så har jag farhågor om att den kan komma att missbrukas precis som med TSQL i gui så kan LINQ queries läggas i gui där de absolut inte hör hemma. Hoppas MS lär ut rätt så att de läggs i repositories där de hör hemma.

Medlem sedan nov. 20014 054 inlägg
#9

Nickemannen skrev:

Jag tycker att tekniken är bra, dock så har jag farhågor om att den kan komma att missbrukas precis som med TSQL i gui så kan LINQ queries läggas i gui där de absolut inte hör hemma. Hoppas MS lär ut rätt så att de läggs i repositories där de hör hemma.

Dvs om man följer repository pattern dvs.. en del delar inte in sina applikationer i flera lager, utan dunkar in data och affärslagret och presentationen i samma, på sin höjd har man spottat ut en del i Codebehind..

Medlem sedan jan. 20022 440 inlägg
#10

Gladh skrev:

Största nackdelen med LINQ To SQL är helt klart de obefintliga möjligheter till "egar loading". Att ha ett objekt som innehåller andra objekt och försöka få LINQToSQL att fylla alla dessa objekt direkt utan femtiåttamiljoner sqlanrop är helt omöjligt...

- M

Ja det också i EntityFramework:

IList<User> userList = userRepository.GetAll();

userList[index].Address.Load();
Address address = userList[index].Address;
foreach(var stuff in Address)
{
    Response.Write(stuff);
}

Det går även att pre-loada allting men varför skulle man vilja det? :)

Medlem sedan maj 20012 812 inlägg
#11

catZ skrev:

Det går även att pre-loada allting men varför skulle man vilja det?

Prestanda!!!

Dessutom har du tittat i SQL Profiler på ditt exempel som du skrev, för vad jag kom fram till så kunde LINQ to SQL endast inkudera ett objekt i user, så om det fanns fler objekt i user eller objekt i Adress så blev det en extra sqlfråga per objekt som skulle hämtas från databasen, och med några tusen objekt och deras underobjekt som skall hämtas, så blir det en del extra frågor som är ganska prestandakrävande när man skulle klara av det med färre frågor...

- M

Medlem sedan okt. 200850 inlägg
#12

Nu susar det i säven!

EF stödjer eager loading.. kör med Include.. vi kan även få deferred loading genom att anropa Load().. i v 2.0 så kommer vi kunna få Lazy Loading out of the box (iofs är jag inget fan av Lazy Loading).

Prestandan i EF är inte lika bra som i L2S, men vi får så mycket med i EF och i framtiden ännu mer.. så jag tycker ibland att vi ska inte fokusera så mycket på prestanda, om det inte är ett problem..

Linq 2 SQL kommer inte läggas ner (jag vill att det ska läggas ner).. Det kommer bara inte lägga något spec fokus på L2S, vilket kommer leda till att få kommer ev använda det i framtiden, och på så sätt läggs det ner :P

Att köra med LINQ i projekt är helt underbart, funkar jättefint.. fördelen är att vi sparar både tid och blir mer effektiva i vårt kodande.. Jag säger bara GO FOR LINQ!

Medlem sedan jan. 20022 440 inlägg
#13

Håller med Fredrik, i vissa fall vill man preloada allting. I ett projekt jag håller på med så ville jag finslipa hastigheten och då fungerar det utmärkt med Include. Exempel:

IOrderedQueryable<Invoice> query = from i in context.Invoice.Include("Workday").Include("Product")
								   orderby i.InvoiceNumber descending
								   select i;

IList<Invoice> invoiceList = new List<Invoice>();

foreach (Invoice i in query)
{
	foreach (Product p in i.Product)
	{
		i.ProductTotal += (p.Quantity * p.UnitPrice * (p.ProfitRate.AddPercent())) * i.GST.AddPercent();
	}
	foreach (Workday w in i.Workday)
	{
		i.WorkdayTotal += i.GST.AddPercent() * (i.HourPrice * Convert.ToInt32(w.Quantity));
	}

	i.KmTotal = i.GST.AddPercent() * (i.Km * i.KmPrice);
	i.InvoiceTotal = (i.WorkdayTotal + i.ProductTotal + i.KmTotal);

	invoiceList.Add(i);
}

return invoiceList;

Problemet är bara att man blir så lat när man inte behöver tänka :P

135 ms totalt · 3 externa anrop · v20260731065814-full.b746b907
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
133 ms — hämta tråd, inlägg och bilagor (db)