<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Mi lesz a következő ADO.NET-ben?</title>
	<atom:link href="http://soci.hu/blog/index.php/2006/09/26/mi-lesz-a-kovetkezo-adonet-ben/feed/" rel="self" type="application/rss+xml" />
	<link>http://soci.hu/blog/index.php/2006/09/26/mi-lesz-a-kovetkezo-adonet-ben/</link>
	<description>Az ember kivételével minden állat tudja, hogy a legfontosabb dolgunk az életben: élvezni azt.</description>
	<pubDate>Fri, 18 May 2012 10:47:14 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Budai Péter</title>
		<link>http://soci.hu/blog/index.php/2006/09/26/mi-lesz-a-kovetkezo-adonet-ben/#comment-2634</link>
		<dc:creator>Budai Péter</dc:creator>
		<pubDate>Tue, 26 Sep 2006 17:58:10 +0000</pubDate>
		<guid isPermaLink="false">http://soci.hu/blog/index.php/2006/09/26/mi-lesz-a-kovetkezo-adonet-ben/#comment-2634</guid>
		<description>Szerintem nagyon durván jó lett, főleg a c# 3.0-val. A DLinq tényleg OR mapper-szerű, viszont ami nagyon tetszik, az a LINQ SQL szintaxisa a collectionökre providermodellestül-mindenestül, meg hogy ez az egész végre párhuzamosításra is jó módszer lesz a PLINQ-kel. 

var q =
	from c in Customers
	where c.City == "London"
	select c;

és akkor mondjuk mindez egyszerre több szálon, adott esetben hashtáblákon keresztül automatikusan optimalizálva fut le. Szép is lenne végre. Amikor már nem azt mondjuk meg, hogy hogyan akarjuk elérni az eredményt, hanem azzal tudunk foglalkozni, hogy mit szeretnénk elérni, és az optimalizációt rábízzuk a motorra. Még a párhuzamosított, multi core környezetben egyre fontosabbá váló "query plant" is cacheli a motor, tisztára mint az SQL. 

És akkor még gondoljuk ehhez hozzá, mi történik majd, ha az Orcas idején kijön a Software Transactional Memory a Vistában most érkező, Kernel szinten megvalósított KernelTransaction kezeléshez csapódva, ami már NTFS és Registry terén képes a tranzakciók kezelésére. Lehet, hogy végre lehet majd a kliensoldalon is hatékony, multicore-ra is skálázódó, többszálas kódot írni? Nemár :) El se hiszem.

Node az is ide tartozik (számomra, bár az ADO.NET-től már messze járok), hogy végre a lockolást is egyszerűsítik, és nem kell szupermennek lenni több párhuzamos szál értelmes és hibamentes kezeléséhez.</description>
		<content:encoded><![CDATA[<p>Szerintem nagyon durván jó lett, főleg a c# 3.0-val. A DLinq tényleg OR mapper-szerű, viszont ami nagyon tetszik, az a LINQ SQL szintaxisa a collectionökre providermodellestül-mindenestül, meg hogy ez az egész végre párhuzamosításra is jó módszer lesz a PLINQ-kel. </p>
<p>var q =<br />
	from c in Customers<br />
	where c.City == &#8220;London&#8221;<br />
	select c;</p>
<p>és akkor mondjuk mindez egyszerre több szálon, adott esetben hashtáblákon keresztül automatikusan optimalizálva fut le. Szép is lenne végre. Amikor már nem azt mondjuk meg, hogy hogyan akarjuk elérni az eredményt, hanem azzal tudunk foglalkozni, hogy mit szeretnénk elérni, és az optimalizációt rábízzuk a motorra. Még a párhuzamosított, multi core környezetben egyre fontosabbá váló &#8220;query plant&#8221; is cacheli a motor, tisztára mint az SQL. </p>
<p>És akkor még gondoljuk ehhez hozzá, mi történik majd, ha az Orcas idején kijön a Software Transactional Memory a Vistában most érkező, Kernel szinten megvalósított KernelTransaction kezeléshez csapódva, ami már NTFS és Registry terén képes a tranzakciók kezelésére. Lehet, hogy végre lehet majd a kliensoldalon is hatékony, multicore-ra is skálázódó, többszálas kódot írni? Nemár :) El se hiszem.</p>
<p>Node az is ide tartozik (számomra, bár az ADO.NET-től már messze járok), hogy végre a lockolást is egyszerűsítik, és nem kell szupermennek lenni több párhuzamos szál értelmes és hibamentes kezeléséhez.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

