Någon som har sett något bra exempel på hur man använder Linq to SQL som O/R-mapper. Det jag är ute efter är ett mer praktiskt exempel, jag har sett flera tidigare men de har varit triviala, dvs kod rätt i GUI-lagret. Blir det inte med LinQ transparent om du ställer frågan mot SQL eller mot datalager? Jag är inte säker på att vi talar om samma sak. Det är inte LinQ i sig jag syftar på utan tillägget i Orcas som heter "LinQ to SQL" där man med en designer mappar databasen mot affärsobjekten. Här är en bra beskrivning : "men sedan när det blir praktik av det så sitter man fast utan kontroll över det som händer "under huven"." <b>Abstraktionsnivåer är bra, det innebär att du kan fokusera på det som är viktigt för dig. </b> Hmm kul grej, "Linq to SQL" försöker ändra tabellers namn från pluralis till singularis. Kan ju vara användbart om det inte vore för att den döpte om "Status" till "Statu" :-) Sen kunde det ju också vara intressant att veta hur Linq to Entities passar in i pusslet.. LINQ är bara ett sätt att ställa frågor mot object.. tex: Nu måste jag dock ställa en svår fråga (jag tror att den är svår att svara på därför att det finns för många faktorer som påverkar) : <b>När kommer "Linq for Entities"?</b> ADO.Net Entity Framework kommer att komma under 2008, det finns ingen tid satt.. så dumt att spekulera redan nu.. låt oss säga "det finns inte idag och däför vet vi inget, så vi tar inte beslut efter det ;)" "Det är dumt att bygga en design efter databasen, så om din model du skapar passar perfekt mot ditt databas schema. Fine use LINQ for SQL.. om inte låt bli ;)" Du kan använda dig av Joins i LINQ, men mappningen som sker, görs mot databas schemat, JOINS har du i frågan.. inte i schemat.. hänger du med? >Det bästa med ADO.Net Entityframework är att utvecklare behöver inte fokucera på infrastrukturen, vi Om applikationen kräver 40 textfält så behöver den det, sen är det upp till den som skapar datamodellen att se till så att det lagras så effektivt som möjligt. Oj, detta svar kan bli långt ;) Jätteintressant tråd! Men hur är det med specen numera egentligen, jag antar att det ska bli en sk model first approach nu med fördröjningen, men är detta bekräftat från officiellt håll? Målet är att det skall vara möjligt, men från början var det inte intressant för ADO.NET teamet. De trodde att POCO bara handlade om en principsak med inget direkt värde.Linq to SQL - Orcas
Försvinner behovet av ett datalager med Linq to SQL? Den verkar ju generera SQL (alt koppla till en SP) och fylla på datan automagiskt?
Tappar man inte kontrollen över detaljer om man använder denna lösning? Det är ju inte helt ovanligt att man gör det när man använder sådana här tekniker som bara helt magiskt löser allt (i ett trivialt exempel) med några rader kod, men sedan när det blir praktik av det så sitter man fast utan kontroll över det som händer "under huven".Sv: Linq to SQL - Orcas
Det blir ungefär samma syntax i frågan.Sv:Linq to SQL - Orcas
http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx
Inser dock nu att detta var ju bara del 1 i en serie på tre inlägg på ScottGu:s blogg, svaret på min fråga kanske finns i de andra två inläggen. Jag får läsa vidare, helt enkelt...
[Edit : Lägger till länkarna till del 2 och 3 också...]
Del 2:
http://weblogs.asp.net/scottgu/archive/2007/05/29/linq-to-sql-part-2-defining-our-data-model-classes.aspx
Del 3:
http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspxSv:Linq to SQL - Orcas
Du menar som när SqlClient översätter från TCP/IP och TDS (SQL servers interna språk) automatiskt?.
Abstraktionsnivåer är bra, det innebär att du kan fokusera på det som är viktigt för dig. Det gäller bara att abstrahera rätt saker (ang abstraktion läs gärna min och fredriks poster om det.http://www.lowendahl.net/showShout.aspx?id=136 http://fredrik.nsquared2.com/ViewPost.aspx?PostID=437)
ang LINQ to SQL så kommer det gå alldeles utmärkt att jobba i "riktiga" projekt. LINQ to SQL är en ORM och ORM har funnits och fungerat i massor av år, bara inte som produkt från Microsoft.
LINQ är ett eget frågespråk. Det innebär att du kommer ställa dina frågor på precis samma sätt oavsett om du frågar mot data i minnet eller mot SQL. Du kan dock inte kombinera dem och ha hälften i minnet och andra hälften i en SQL databas, då måste du ställa två frågor.
Vad LINQ to SQL ersätter är inte data lager utan den ersätter helt enkelt data access koden. Så samma saker gäller som innan, att du kapslar in och återanvänder dina frågor i olika gateways / repositories osv.Sv: Linq to SQL - Orcas
Visst, det håller jag absolut med om, produktivitet är mitt ledord, annars hade jag fortfarande kodat assembler.
Vad jag är orolig för när det gäller alla nya tekniker, är vad man inte kan styra. Kan man t ex i LinQ optimera frågorna som genereras, t ex vad det gäller vilken typ av Join som skall användas, eller isolation level (WITH NOLOCK) e t c.
Jag tycker det ser riktigt lovande ut, men jag har väldigt lite erfarenhet av att bygga "riktiga" affärslager med O/R-mappers, factories, repositories och allt vad det nu heter. Eftersom jag är på gång att skriva om en av mina produkter (som tyvärr använder typade datasets hela vägen upp till GUI:t :-( ) så vill jag satsa på rätt teknik. Gör om och gör rätt helt enkelt...
En annan fråga. : Det verkar ju som att LinQ nu gör det mesta av jobbet åt datalagret, och dessutom sköter det som jag inbillat mig att repositories/factories skall sköta, vad blir det kvar? Uppenbarligen har jag lite luckor i kunskapen här :-)
Ps. Vad är en gateway i arkitektur-sammanhang?Sv:Linq to SQL - Orcas
Sv: Linq to SQL - Orcas
Sv:Linq to SQL - Orcas
List<Int> numbers = new List<int>() {1,2,3,6,5,7,8};
var values = from n in numbers
where n > 3
select n;
Sedan har MS skapat ett flertal "ramverk" för att kunna använda LINQ mot tex Entiteter, Databas, DataSet och XML etc. Vi har tex "LINQ for SQL". Där våra frågor i kod omvandlas till SQL, och själva "LINQ to SQL" ramverket kommer göra data accessen åt och och fylla objekt med den informationen vi vill ha ut. Fördelen med detta är att vi får kompilerings fel om våra frågor är fel skrivna.. det får vi inte om vi skulle skriva SQL och lägga det i en sträng och skicka in det i en SqlCommand.
"LINQ for Entities" kommer att komma med nästa generation av ADO.Net framework, som kommer har namnet ADO.Net Entity Framework.
Problemet med LINQ for SQL är att du mappar mot databas schemat, samt att du kan inte säga att vissa delar av dina entitier ska hämtas från olika tabeller etc. Så detta är ett alternativ för er som vill skriva databas-drivna app och inte har en domain-model.
LINQ for Entities fungerar så att vi kan ställa frågor med LINQ mot en conceptual model. Vi kommer med hjälp av ett verktyg kunna skapa vår modell och mappa den mot olika datakällor. Vi är inte beroende av databas schemat på samma sätt som LINQ for SQL.. Tex en databas har sina tabeller och det kanske är så att vi vill ha en entitet som heter Customer, som inte bara hämtar data från en tabell utan vår entitet består av data från flera tabeller (det kan inte LINQ for SQL lösa), men LINQ for Entities kan det. Detta är mer likt vad en OR-Mapper så som nHibernate.
Det bästa med ADO.Net Entityframework är att utvecklare behöver inte fokucera på infrastrukturen, vi skapar vår modell, sedan låter vi administratörer (tex DBA) mappa den mot en eller flera datakällor.. Sedan ställer vi frågor med hjälp av LINQ mot vår skapade modell.. Coolt va!!!
LINQ for SQL kommer idag att generera SQL, vad jag vet så kan vi inte ändra på hur den gör det.. Men det är inte intresant.. jag litar på Microsoft. Tycker vi det är intresant att kunna, då har vi alternativet att även använda Stored Procedures. LINQ for SQL klarar av användandet av Stored Procedures också. Men varför ska vi utvecklare fokucera på Stored Procedure och den SQL som skapas? Läs min post och Patrik om vaför vi undviker Stored Procedures och låte OR-Mappers generera SQLen:
http://fredrik.nsquared2.com/ViewPost.aspx?PostID=433
http://www.lowendahl.net/showShout.aspx?id=142
LINQ for Entites, kan mer eller mindre bytas ut mot en OR-mapper i Repositories. Tex nHibernate har sitt HQL för att kunna ställa frågor, se LINQ som en ersättning av HQL.. och ADO.Net Entity Framework som en erstättare till nHibernate.
Om jag inte har fel så kommer Jimmy Nilsson prata om LINQ i DDD på Öredev i November.
/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.com
Ps. Om ni är intreserade av arkitektur så är SweNug Architect Summit ett måste ;)
http://fredrik.nsquared2.com/ViewPost.aspx?PostID=435Sv: Linq to SQL - Orcas
Är det dumt att satsa på "LinQ to SQL" eftersom den, som du säger, är databasdriven? I mitt fall har jag en existerande databas, som jag dock har full kontroll över och kan ändra designen när jag vill (fast det är ju en del jobb med att hålla datan intakt mellan versionen om man ändrar för mycket). Övriga alternativ är som jag förstår det att vänta på "LinQ for Entities" eller att gå till NHibernate eller annan O/R-mapper.
Jag står nämligen inför vägvalet nu att sätta igång och göra ett helt nytt affärslager och datalager för min applikation, eller att avvakta tills bättre verktyg finnes.
När kommer "Linq for Entities"?Sv:Linq to SQL - Orcas
Om jag förstått det rätt, så H1 2008 (antagligen i samband med nästa version av SQL Server)Sv:Linq to SQL - Orcas
Om det är du som bygger applikationen för eget bruk, så gör det som känns bäst för dig. Jag skulle inte väntat på "LINQ for Entity" om jag måste bygga om den NU. Men LINQ finns inte idag, det kommer och ev i höst i RTM. Så det val du har nu är att köra med tex nHibernate om du vill använda dig av en OR-mapper. Men om det är så att du vet att din app blir klar efter hösten, kanske in på 2008. Då kan du med försiktighet börja använda LINQ genom att köra med "Orcas" betan..men tänk på att vägen till RTM, kan innebära många förändringar, som kan leda till att det tar längre tid att skriva om appen.
Det är dumt att bygga en design efter databasen, så om din model du skapar passar perfekt mot ditt databas schema. Fine use LINQ for SQL.. om inte låt bli ;)
Lät rätt elak där.. så va inte tanken ;)
/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.comSv: Linq to SQL - Orcas
Där sa du något som var riktigt intressant, är det verkligen så att man måste köra efter en och samma tabell, kan man inte använda någon sorts join i LINQ?
Det ni skriver om LINQ for Entities skulle vara en ersättare eller jämlik som NHibernate, hur fungerar det med Lazyload och cascade savings och sådant? :).
Jag följer utvecklingen av LINQ med spänning, hade varit intressant att se ett datalager exempel byggt med det med innehållande repositories, factories (eller factoryn kanske ersätts nu? och entiteter.Sv:Linq to SQL - Orcas
LINQ for Entties ersätter inte factories eller Repositories.. utan LINQ for Entity ersätter nHibernate om du tex vill det... LINQ For Entities hör till infrastructure layer.. Där du ev kommer att använda LINQ, är i dina Repositories och i dina specification.
/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.comSv: Linq to SQL - Orcas
>skapar vår modell, sedan låter vi administratörer (tex DBA) mappa den mot en eller flera datakällor..
>Sedan ställer vi frågor med hjälp av LINQ mot vår skapade modell.. Coolt va!!!
Låter inte det ganska farligt ur prestandasynpunkt? Vad säger att modellen går att implementera på ett effektivt sätt i datakällan.
Ser framför mig utvecklaren som har använt en modell bestående av 40 textfält som han sen lämnar över till administratören för mappning mot SQL databasen.Sv:Linq to SQL - Orcas
Databasen är en lagringsplats, där tar man beslut som är bäst för lagringen, applikationen är där arbetet skall utföras, där tar man beslut baserat på vad applikationen skall göra. Den ena skall inte påverka den andra utan du skall ha ett översättningslager emellan som ser till att du kan vara så effektiv som möjligt på båda sidor. Sv:Linq to SQL - Orcas
Men jag ska göra mitt bästa för att svaret ska bli så bra som möjligt.. så håll i er..
Utvecklare har under lång tid kämpat med skillnaden som finns att skapa affärs applikationer och data åtkomst och sparning av data på ett effektivt sätt och behovet av att leverera data till användare i ett begriplig och vänligt format. Detta gap har ofta blivit ett fördärv i utvecklarens tillvaro. Med abstraktioner så fokuserar man nu på att göra utvecklaren mer effektiv genom att få dom att fokucera på att bygga affärslösningar istället för spendera värdefull tid på data programmerings detaljer på låg nivå.
Sysftet är också att få verksamheten närmre utvecklarna. Att få dom att effektivare jobba tillsammans och prata samma språk. Genom att skapa en modell som båda förstår, vilket underlättar gapet mellan utvecklare och verksamheten.
Utvecklare borde fokucera mer på vad han eller hon gör bäst, vilket är att bygga lösningar utan att de ska behöva bry sig om det fysiska sättet att spara data. Genom att uppnå detta så leverear tex Microsoft en ny teknik "ADO.Net Entity Framework", som ska ger utvecklare möjligheter att jobba med data på en högre och mer intuitiv abstraktions nivå (begreppsmässig istället för följdriktig). Med ADO.Net Entity Framework så kan utvecklare hämta deras data baserat på definierade affärs entiter, så som kund och produkt, där han/eller hennes data kanske sparas på flerar tabeller. Genom att använda ramverk som ADO.Net Entity Framework eller tex nHibernate (för att inte fastna på ett ramverk), så kan utvecklare fokusera mer på begreppet att säga, hitta en kund i en viss region istället för att fundera ut var och hur är datan sparad och i vilka tabeller behöver jag ställa min fråga mot för att få den data jag behöver. Med dessa ramverk så kan utvecklare fokusera på modellen, medans administratörerna kan forstätta fokusera på att definiera och hantera implementationen av modellen som en databas, tabeller och kolumner. Deras uppgift blir att på bästa möjliga sätt, skapa en databas, skapa en mappning mot modellen som och även se till att levererar bra prestanda.
Vad utvecklare kan göra, är att själva öka prestandan genom cachning, genom olika patterns, genom bra optimerad kod etc. Med en bra modell, så är det lättare för utvecklare att se hur och vad de ska cacha än med en dålig modell som byggs efter att databasen ska leverera bra prestanda.
/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.comSv: Linq to SQL - Orcas
En annan sak är att den konceptuella modellen (entitymodellen) som jag fattat det kommer att ligga i sin egen assembly, vad jag skulle vilja är att kunna persista POCOs a la Hibernate eller Java Persistence API. Dvs att man skapar sin domänmodell "på gammal hederligt sätt" (typ Person.cs osv) och sedan jobbar mot den med sina repositories där man hanterar lagring och hämtning med linq to entities. Kommer detta att vara möjligt?Sv:Linq to SQL - Orcas
Fördröjningen beror på flera saker, men bland annat tar de den extra tiden för att försöka få till model-first som en möjlig approac för att använda EF.