Microsoft versimpelt databasetoegang met Entity Framework

Microsoft heeft een tweede bètaversie van het ADO.Net Entity Framework vrijgegeven. Verder heeft het softwarebedrijf een aantal tools gepubliceerd, die bedoeld zijn om in combinatie met het framework gebruikt te worden.

Het ADO.Net Entity Framework is een Object-Relational mapping-technologie, waarmee gegevens uit een relationele database eenvoudig kunnen worden omgezet in objecten met gegevens die door objectgeörienteerde programmeertalen gebruikt kunnen worden.

Een belangrijke functie binnen het nieuwe framework is het automatiseren van taken. Op dit moment is het zo, aldus productmanager Britt Johnston, dat veel ontwikkelaars in hun code zelf de conversieslag tussen database en applicatie moeten maken. Volgens Johnston zorgt het Entity Framework ervoor dat data op een eenduidige wijze aan de ontwikkelaar ter beschikking gesteld wordt, zodat er op een abstractere manier mee gewerkt kan worden.

Nieuw in het framework zijn onder meer de ondersteuning voor complexe types en de mogelijkheid om keys te serializen. Verder is ondersteuning voor metadata-annotaties ingebouwd en wordt de Language Integrated Query beter ondersteund. ADO.Net Entity Framework Tools bevat onder andere de ADO.Net Entity Designer, waarmee op een visuele manier relationele objectmodellen en -mappers voor gebruik in Visual Studio 2008 Beta 2 gebouwd kunnen worden.

Het is de bedoeling dat het ADO.Net Entity Framework in het begin van 2008 uitgerold wordt, als onderdeel van versie 3.5 van het .Net-framework. De tools zullen onderdeel zijn van Visual Studio 2008 en naar verwachting eind februari 2008 op de markt komen.

Reacties (44)

[PolarBear]

Voor uitgebreidere uitleg zie hier en de download hier.

Ik ben er erg blij mee, er zijn al wat O/R mappers vvoor .Net zoals NHibernate maar ik vind het wel fijn dat dit soort belangrijke functionaliteit onderdeel wordt van het .Net framework.

Het .Net platform is in redelijk korte tijd (2000 was de eerste beta) uitgegroeid tot een geduchte concurent van het 5 jaar oudere JAVA.

[Reactie gewijzigd door PolarBear op 30 juli 2024 01:51]

[Verwijderd]

Indien je de download link geeft moet je wel de goede geven.
Jouw link was van de juni CTP.

http://www.microsoft.com/...2ee11186f7&DisplayLang=en is de juiste download

[SPee]

De laatste versie is niet 5 jaar oud.

Java 6 is sinds afgelopen December beschikbaar.

En daar hebben ze al die OR mapping in de taal opgenomen. Dus Hibernate is niet meer nodig.
BTW: Hibernate bestond voor NHibernate, dus het lijkt mij dat het '5 jaar oudere' Java voorloopt op MS.

[riezebosch]

Er wordt nergens beweerd dat de laatste versie 5 jaar oud is, en ook niet dat MS met .NET voorloopt op Java. De vergelijking is dat MS in een redelijk korte tijd een geduchte concurrent heeft neergezet voor Java.

[Verwijderd]

Wat?
Er zit geen ORM in Java 6 SE.
Gelukkig niet trouwens. Dat hoort daar niet in thuis.

[seppevs]

Nee, maar wel in Java EE.

[Verwijderd]

Java 5 EE ja.
En het is niet zo dat Hibernate niet heel nuttig is door de komst van EJB3.
Die twee dingen sluiten elkaar niet eens uit.

[GoBieN-Be]

Maar JAVA is cross platform of toch zo goed als ...

.NET verre van

[afterburn]

JAVA is ook traag en vreet geheugen. Als je met cross-platform bedoelt dat het op geen enkel platform echt fatsoenlijk draait geef ik je gelijk. Op mijn werk redelijk wat te maken met TIBCO software. Je wordt er gewoon gillend gek van.

Programmeurs zouden weer fatsoenlijk moeten leren programmeren ipv het creeren van een zogenaamd universele brij in een VM of met sleur en pleur wat universele functies bij elkaar vegen met als resultaat gigantische programmas met weinig functionaliteit die niet performen en geheugen vreten alsof het niks kost.

C is ook prima cross-platform te gebruiken, mits de programmeur weet waar ie mee bezig is en vanaf het begin rekening houdt met meerdere platforms. De binairies zijn kleiner, performance is dramatisch beter.

Maar ja, een goede C programmeur kost meer en heeft meer tijd nodig. En dus produceren we liever in korte tijd veel rotzooi en verdienen we extra geld aan support dan dat we in een keer iets goeds bouwen.

Mag misschien cynisch zijn, maar als je elke dag met dit soort rommel te maken hebt wordt je dat vanzelf.

[Verwijderd]

Ik vind deze opmerking redelijk arrogant, kort door de bocht en slecht onderbouwd.

Alle Java en .net programmeurs worden door jouw over een kam geschoren en afgeschilderd als mensen die maar eens fatsoenlijk moeten gaan leren programmeren.

Java en .net bieden vele andere voordelen naast de platform onafhankelijkheid. Zoals bijvoorbeeld (In het gavel van Java) het clusteren van Java EE applicaties op een applicatie server en het bieden van faciliteiten voor transacties, beveiliging en deployment.

"De binairies zijn kleiner, performance is dramatisch beter"
I beg to differ. Voorbeeld: Originele Quake2 code geport naar Java, zie de resultaten: http://www.bytonic.de/html/benchmarks.html . Misschien kan John Carmack gewoon niet goed programmeren....

"geheugen vreten alsof het niks kost"
Los van het feit dat dat afhangt van hoe je de applicatie maakt en het kortzichtig is om te stellen dat dat voor iedere Java of .net applicatie geld:
Ik weet niet waar je de afgelopen 6 jaar gezeten hebt; Maar als je gaat vergelijken wat geheugen gekost heeft in de begin dagen van C en nu kan je stellen dat geheugen niks meer kost. Voor 500 Euro plemp je 8 Gb extra in een server, een een instap server van HP Kost 900 euro. Maar goed, je kan van een ICT'er natuurlijk ook niet verwachten dat hij de ontwikellingen in zijn branch bijhoud...

[seppevs]

Je staat een aantal jaar achter denk ik. Java's performance problemen zijn al lang achter de rug.
En Java programma's werken bij mij even goed onder Linux als onder Windows, dus ik begrijp niet waarom je zegt dat Java op geen enkel platform fatsoenlijk draait.
Wat zijn je argumenten eigelijk?

[psyBSD]

je hebt gelijk, maar ik begrijp afterburn's standpunt wel. Met de hogere programmeer-talen (java, C#) hebben we met een nieuw slag programmeurs te maken. Het type dat nog nooit gehoord heeft van memory-management en efficiency.

En dan zijn er ook nog mensen die zelfs als ze java gebruiken niet schromen er omheen te werken om zo toch aan een platform vast te zitten.

De performance-problemen zijn voor een groot deel te verwijten aan het feit dat JAVA te vroeg kwam. Het was al aanwezig in een tijd dat de machines die extra rekenkracht die nodig is voor een VM niet konden missen. Dit imago heeft java moeilijk van zich af weten te schudden, mede door de slechte kwaliteit van de applicaties die er mee geschreven werden.

Als ik een cross-platform app moet schrijven, en ik moet kiezen voor .NET of Java, dan kies ik Java. Als het echter alleen op POSIX platformen hoeft te draaien, dan prefereer ik C.

[Verwijderd]

Die performance problemen komen naar mijn mening alleen voor op Windows systemen. Dezelfde applicaties op Linux of Solaris draaien aanmerkelijk vlotter en lijken zelfs sneller dan een 'native Windows' applicatie op Windows. (Dat laatste is echter puur persoonlijke perceptie en kan ik niet onderbouwen met metingen.)

Wat je aankaart betreffende het nieuwe slag programmeurs dat weinig kaas heeft gegeten van memory-management, efficiency, etc. kan ik (helaas) alleen maar bevestigen.

[sorted.bits]

Dus eigenlijk is dit alleen maar een flame, juist omdat je er onder zet dat je .net haat.

Waarom dan? Ok, ik snap dat er nu een hele reeks nieuwe noobie programmeurs bij komt, op deze manier, maar waarom zou jij daar problemen mee hebben?

Wanneer je gewoon gestructureerd programmeert in .net is er ook niets aan de hand. Het zijn vlotte applicaties, welke erg snel opgezet kunnen worden.

[hackerhater]

Eigenlijk zou ik moeten zeggen dat ik visual studio haat (ja heb er mee gewerkt)
De code wat dat programma maakt is zo gruwelijk ineffecient.
JAVA draait nog beter

En ik vind dingen van c#/.net gewoon super onlogisch.
- Maakt geen onderscheid tussen de benamingen van variabelen, functies en klasse-variabelen
- klasse-variabelen zijn te benaderen zonder this. te gebruiken
- Form variabelen zijn qua code niet te onderscheiden van klasse-variabelen
- ect

Ik heb problemen met die slechte manier van "programeren" omdat hierdoor resources verspild worden. Onze computers worden steeds sneller, maar de programma's worden steeds lomper. Uiteindelijk ga je er geen zak op vooruit.

[afterburn]

Geloof je best hoor, maat enterprise software loopt over het algemeen niet voorop met het accepteren van de nieuwste versies. Voor de software waar ik dagelijks profesioneel mee te maken heb gaat het dus nog steeds op. En aangezien de zooi op zowel Solaris als Windows wordt gebruikt, en bij beide het geheugen gebruik de pan uit rijst en performance op zijn zachts gezegd niet optimaal is...

Het kan wel goed draaien hoor, maar als je dan ziet wat er eigenlijk door zo'n programma wordt gedaan en wat voor hardware erachter zit, dan zou je je toch eens af moeten vragen waar men in Gods naam mee bezig is.

Er wordt te vaak en te makkelijk gewoon zwaardere hardware tegenaan gegooit. Werkt prima hoor, maar dat is als met een olifant op een mug schieten. Ipv schermen met multicore multicpu machines met vele gigabytes aan geheugen zou men eens een beetje meer naar de code moeten kijken.

[SilenceTi]

.NET draait ook op linux met behulp van MONO.

Met de komst van Silverlight 1.1 draait .NET code, weliswaar iets afgeslankt vanwege web, ook op de Mac (clientside).

[cablepokerface]

Dat .NET multi-platform is vanwege mono is een fabel. Ik moedig je aan om mono aan de praat te krijgen (op debian) ofzo en er een .NET app op te laten draaien.

Feit is dat er voor iedere .NET app (zeer) grote wijzigingen nodig zijn om het te porten naar mono vanaf het windows platform.

Wie weet is dat in de toekomst anders maar op dit moment zit mono nog mijlenver van .NET multi-platform maken.

[Verwijderd]

De .NET standaard is wel degelijk open EN gemaakt met cross-platform in gedachte.

En met Mono kun je al je .NET dingetjes ook lekker op *nix draaien.

[Ajunne]

Niet helemaal correct. Het verschil zit hem in het feit dat Java standaard out-of-the-box en met officiële support van Sun op een hele rits achitecturen en besturingssystemen draait. Bij .net was het nodig dat de open source community zelf een framework in elkaar zet om .net ook op iets anders dan Windows te laten draaien.

Het feit dat Mono niet door Microsoft zelf wordt gemaakt impliceert dat ze altijd een achterstand zullen hebben op de officiële .net standaard, en dat niet iedereen dus meteen alle laatste nieuwe snufjes kan gebruiken, totdat iemand de nieuwe code in Mono toegevoegd heeft.

Sun brengt steeds nieuwe versies op alle platforms tegelijk uit (ze kunnen ook moeilijk anders, aangezien Java software op heel veel verschillende systemen in productie draait momenteel, waarbij waarschijnlijk Linux op x86 en Solaris op SPARC de meest voorkomende zijn. En natuurlijk Windows op x86 voor de clientside).

[cablepokerface]

En met Mono kun je al je .NET dingetjes ook lekker op *nix draaien.

Zoals ik boven bij een soortgelijke reactie aangeef. Dat is een fabel. Probeer een van je .NET apps maar eens op mono te laten draaien zonder grote lappen code aan te passen. Gaat echt niet lukken.

Jammer dat microsoft kan claimen dat .NET multi-platform is door mono. .NET is alleen multi-platform over windows versies zelf (wat al een belangrijke verbetering is, daar niet van).

Je app 1 op 1 poorten naar mono; je komt van een koude kermis thuis.

[Verwijderd]

Gaan we nu bij een bericht over een ORM product een hele discussie voeren over .NET versus JAVA waar iedereen over elkaar struikelt om dezelfde oude argumenten uit de kast te trekken?

Interessant zeg...

[SuperDre]

Ach de zoveelste onzin... ADO zelf werd ook gezegd dat je met 1 objectmodel alles aan kunt wat er achter zit.. Yeah right... je moet nog steeds net zoveel rekeninghouden met wat er achter zit als met de voorloper DAO, alleen dan is het nog een stuk trager..

Ik heb het ondertussen gehad met al die frameworks die het werk moeten verlichten, elk bedrijf komt met zijn eigen framework, terwijl het eigenlijk helemaal niets toevoegd aan de al bestaande dingen. Het enige dat nodig is bij de nieuwe dingen is nog snellere computers met nog meer geheugen om precies hetzelfde te bereiken wat we al 4 jaar geleden konden..

[StainlessSteel]

Wij hebben ook een framework ontwikkeld, dit wordt echter alleen binnen het bedrijf gebruikt. Door dit framework hoeven wij ons nooit meer zorgen te maken over database onafhankelijke software, logging, caching en voornamelijke al die kleine dingen die je normaal bij elk project opnieuw zou moeten maken. Daarnaast zorgt het framework voor een gestandaardiseerde aanpak en geeft het een solide basis om applicaties mee te maken.

Frameworks zijn niet slecht. Implementeer jij maar eens wat ORM-achtigs. Ik denk dat je dan blij bent dat iemand dat al voor jou heeft gedaan. En waarschijnlijk nog goed getest is ook.

[eghie]

Maar onderhouds technisch is het wel makkelijker. De database code hoef je, bij een goed framework, maar op 1 plek te onderhouden. Dit scheelt een hoop. Ook kun je met zo'n framework makkelijker multi-DBMS werken.

Nadeel is inderdaad wel dat het trager kan worden, maar het kan ook sneller worden vanwege de caching mogelijkheden en connectie beheer. Slurpt wel iets meer geheugen. Ook is een nadeel met een framework, om geavanceerde dingen, die je met je database kunt doen, te regelen, aangezien dat vaak afwijkt van de standaard manier van het framework.

[daft_dutch]

ik vraag me af hoe de queries in elkaar steken.
msSQL heeft een query analyser die deze optimaliseert. (tot een zekere hoogte)
Oracle heeft dat niet die kan je veel verder tweaken maar dan moet je er wel verstand van hebben.

Als dit frame work dan met standaard queries aan de gang gaat. kan dat een stuk langzamer zijn.
vooral met * naar * relaties.

anyway mooie MS tool voor een MS omgeving.
ze doen het wel weer.

[NLxAROSA]

Mijn ervaring met ORM tools is dat ze voor het standaard werk zeer geschikt zijn. Voor zaken als bijvoorbeeld complexe zoek-queries zijn ze minder geschikt. Dan kun je die queries beter in SQL schrijven. (Wat ORM tools als Hibernate dan ook prima ondersteunen) Veel mensen denken nogal eens dat je niet meer naar de database en de uitgebraakte SQL hoeft te kijken als je een ORM tool gebruikt, maar dat is een groot misverstand.

[Reactie gewijzigd door NLxAROSA op 30 juli 2024 01:51]

[Shift]

Voor jou onzin is niet voor iedereen onzin. Heb je je wel verdiept in ADO..NET EF of reageerje gewoon uit verveling.

Hier heb je een demo van van deze framework.

http://channel9.msdn.com/ShowPost.aspx?PostID=217633

[Verwijderd]

Een demo door de fabrikant zal er altijd uitzien als een enorme vooruitgang he!

Wij van wc eend....

[Shift]

De inhoud van de demo kan je zelf beoordelen, heeft niets met je wc eend verhaal mee te maken.

[EfBe]

Een belangrijke functie binnen het nieuwe framework is het automatiseren van taken. Op dit moment is het zo, aldus productmanager Britt Johnston, dat veel ontwikkelaars in hun code zelf de conversieslag tussen database en applicatie moeten maken. Volgens Johnston zorgt het Entity Framework ervoor dat data op een eenduidige wijze aan de ontwikkelaar ter beschikking gesteld wordt, zodat er op een abstractere manier mee gewerkt kan worden.

Ja en dat is tegenwoordig niet mogelijk, he Microsoft? Ze leven echt in een ivoren toren soms. Zelfs intern hebben ze een concurrent, linq to sql.

Het EntityFramework is overigens helemaal niet 'simpel'. Om uit te leggen wat de verschillen zijn met bv linq to sql heb je wel degelijk veel kennis nodig van wat het entity framework inhoudt en ik heb nog maar weinigen gezien die het echt snappen.

[svenM]

eh linq to sql en het entity framework zijn toch niet echt concurrenten hoor.

linq to sql is rechtstreeks naar SQL (en dus enkel sql), is ook 1 op 1 gekoppeld aan een datasource,
entity framework heeft 3 lagen en is meer flexibel

linq to sql is meer voor kleinere programma's

iets meer uitleg : http://www.thedatafarm.co...SQLVsEntityFramework.aspx

[Verwijderd]

Het ADO.NET programma iss ook het programma waarin het WinFS programma uiteindelijk is opgenomen (of verdwenen, het is maar hoe je het bekijkt).

[EfBe]

Welnee man, ADO.NET is gewoon een onderdeel van .NET. Je bent in de war met ObjectSpaces, wat toen gemerged is met WinFS, en waarbij de developers grotendeels toen zijn overgegaan naar het C# team om daar Linq to Sql te maken. In het WinFS team zaten o.a. mensen die nu het EntityFramework leiden, en winfs is gecanceled.

[Verwijderd]

http://blogs.msdn.com/winfs/

[Verwijderd]

Ik hou het toch maar bij LLBLGen 2.5

Kan MS nog wat van leren. Na jaren aanmodderen gaan ze misschien toch nog ooit LLBLGen kopen...

[TeeDee]

Vraag het eens aan de persoon boven je (EfBe) of er interesse is van MS?

[Reactie gewijzigd door TeeDee op 30 juli 2024 01:51]

[EfBe]

Alleen technisch, tot op heden heb ik nog geen bak met geld gezien

[Moartn]

Wie weet dat het in .net nu ook wat gebruikelijker wordt om een O/R-mapper te gaan gebruiken nu Microsoft er zelf ook een oplossing voor heeft. Er zijn natuurlijk al zat oplossingen voor (zoals LLBLGen en NHibernate), maar ik heb het idee dat veel .net-developers zich strikt aan de tools houden die Microsoft hun aanlevert en erg bang zijn om 3rd party libraries te gebruiken terwijl dat in Java eigenlijk altijd gebeurt. Misschien ligt dat aan Visual Studio ofzo, of aan hun mooie MCPD certificaatje waarin je waarschijnlijk ook niets anders leert dan MS-tools.

Begrijp me niet verkeerd, .net is een prima ontwikkelomgeving als je het mij vraagt, maar er bestaat nog wat meer dan wat MS voor je maakt

[dsmits]

Zou microsoft er niet verstandiger aan doen om ipv een tooltje om objecten op te slaan een object georienteerde database te gaan ontwikkelen. Word tooltje ook overbodig.

En van het tooltje zijn inderdaad al verschilende smaken verkrijgbaar.

[Reactie gewijzigd door dsmits op 30 juli 2024 01:51]

[cablepokerface]

Wat interessant dat ik hier niemand tot nu toe de vergelijking hoor trekken met DLINQ. Daar zit ook een ORM in.