Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 37 reacties

Microsoft heeft tijdens een presentatie op de VSLive-conferentie in San Francisco zijn ideeŽn over het werken met data in toekomstige versies van Visual Studio uit de doeken gedaan.

Microsoft Visual Studio-logoData wordt veelal in relationele databases opgeslagen, niet het ideale formaat voor een objectgeoriŽnteerde taal. De laatste jaren zijn daarom zogenaamde Object Relational Mappers sterk in opkomst. Deze orm-tools omvatten een abstractielaag tussen de database aan de ene kant, en de clientapplicatie aan de andere kant. De programmeur van de applicatie hoeft niet meer met de data zelf te werken, maar kan de door de tool gegenereerde objecten rechtstreeks aanspreken. De tussenlaag zorgt er vervolgens voor dat de data weer correct in de database wordt opgeslagen. Een nieuwe klant toevoegen is dan niets meer dan het instantiŽren van een klantobject, de relevante eigenschappen als klantnummer en naam aan het object toekennen, en de 'opslaan'-methode van het object aanroepen.

Codevoorbeeld
Voorbeeld van het toevoegen van een klant met orm

OrcasOp dit moment biedt Microsoft zelf nog geen orm-oplossingen voor het .Net-framework aan. Enige jaren geleden werd met ObjectSpaces een poging gedaan, maar nadat dit initiatief in het WinFS-filesystem is geÔntegreerd, is het als zelfstandig platform een stille dood gestorven. Verschillende bedrijven zijn in dit gat gesprongen en hebben zelf orm-pakketten op de markt gebracht, een voorbeeld hiervan is het Nederlandse LLBLGen Pro. Britt Johnston, verantwoordelijk voor de data-programmeertak bij Microsoft, heeft tijdens een toespraak op de VSLive-conferentie aangekondigd dat Microsoft in de volgende versie van Visual Studio, met de codenaam Orcas, deze achterstand wil goedmaken.

Anders Heljsberg, chief C# architect Een aantal van de oorspronkelijke ontwikkelaars van het ObjectSpaces-project zijn geruime tijd geleden aan iets nieuws gaan werken: Linq. Deze uitbreiding op C# en VB.Net moet het mogelijk maken om door middel van elementen van deze programmeertalen queries te definiŽren. Deze queries worden door de compiler omgezet naar zogenaamde Expression Trees. De trees worden op hun beurt geÔnterpreteerd door een platformspecifieke engine. Zo zorgt de 'Linq to Sql'-engine voor een koppeling met een relationele database; vooralsnog wordt alleen MS SQL Server ondersteund. Uiteindelijk moet met behulp van Linq met data gewerkt kunnen worden alsof deze als object in het geheugen zit, terwijl de data in een database of bijvoorbeeld een xml-bestand is opgeslagen.

Parallel met de ontwikkeling van Linq heeft het SQL Server-team van Microsoft het Entity Framework ontwikkeld. Dit framework creŽert een zogenaamd Entity Data Model dat middels een nieuwe taal - eSQL - kan worden aangesproken. De ontwikkelaar hoeft dus niet meer met het onderliggende datamodel te werken. Een Linq to Entity-engine zorgt ervoor dat ook Linq met edm overweg kan. Feitelijk kan een ontwikkelaar straks kiezen uit de 'Link to Sql'-route, of het werken met entities in combinatie met Link to Entities. De ontwikkeling van twee aparte systemen lijkt vreemd, en verschillende mensen zijn dan ook van mening dat slechts een systeem over zal blijven. Link to Sql heeft inmiddels een zodanig grote achterstand ten opzichte van 3rd-party or-mappers opgelopen dat het te betwijfelen valt of het die achterstand nog wel goed kan maken.

Microsofts Entity Framework (klein)
Het Entity Framework (klik voor grotere versie)

Het Entity Framework is op dit moment technisch geavanceerder, maar is erg complex. Om het voor een ontwikkelaar enigszins toegankelijk te houden is er een aparte edm-designer in ontwikkeling. Het lijkt er echter op dat deze designer de volgende release van Visual Studio niet zal halen. Dit zou een behoorlijke tegenslag betekenen voor de acceptatie van edm omdat een ontwikkelaar dan is aangewezen op een beperkte wizard of de xml-configuratiebestanden met de hand zal moeten aanpassen.

Logo LLBLGen ProFrans Bouma, de ontwikkelaar van het eerder genoemde LLBLGen Pro, gaf in een reactie aan verdeeld te staan tegenover het initiatief van Microsoft. 'Or-mapping is binnen de .Net-wereld nog relatief onbekend. Veel ontwikkelaars werken nog met datasets of een eigen data access layer. Linq to SQL of Entities kan dit veranderen waardoor het concept van or-mapping bekender wordt, en daarmee de markt groter. Een slechte eerste implementatie kan echter nadelig zijn voor het concept omdat mensen niet de juiste indruk van de mogelijkheden van de techniek krijgen.'

Microsoft heeft inmiddels details rond de lancering van de nieuwe versie van Visual Studio bekend gemaakt. De eerste bŤta zal in het tweede kwartaal van 2007 beschikbaar komen, gevolgd door een tweede bŤta halverwege dit jaar. Een datum voor een rtm-versie kon het bedrijf nog niet geven.

Moderatie-faq Wijzig weergave

Reacties (37)

Dit soort ontwikkelingen zijn goed enzo... en erg knap, maar de echte "kunst" van het programmeren gaat wel goed verloren.
Waarom?

Je hebt in je programma een aantal zaken te doen, nl.:
1) de functionaliteit van je programma bouwen, dus wat je programma feitelijk moet doen
2) zorgen dat de code bij 1) werkt, dus z.g. 'plumbing' code maken. (data van/naar database, data laten zien in scherm, input validatie, rule checking engines etc.).

Nu wil het geval dat jij als programmeur ingehuurd wordt voor 1) maar 2) er wel bij moet doen, anders werkt 1) niet. Het punt is nu, dat wanneer je 2) tot een minimum kunt beperken door bv standaard frameworks te gebruiken die 2) voor je verzorgen, je alle aandacht op 1) kunt richten en daar zul je het nog knap lastig mee krijgen.

Gaat het echte programmeren dan verloren? Ik denk het niet, je moet nog steeds problemen oplossen middels het schrijven van programmatuur. De omgeving waarin die oplossingen dan draaien is dan wel voor je klaargezet. Tuurlijk is het soms leuk om te werken aan low-level framework zaken, maar als je daar 40-50% van je tijd mee bezig bent dan heb je dus maar 50-60% van je tijd over voor waar je feitelijk voor ingehuurd bent, en dat lijkt me niet nuttig.
Dus, jij wil elke keer weer het wiel opnieuw uitvinden, of je bezig houden met het schrijven van een data access laag ipv je bezig te houden met wat je programma 'echt' moet doen. De business-functionaliteit zeg maar ?
Ik denk dat dat wel een beetje onzin in. Ik neem voor het gemak maar even aan dat jij refereert naar C(-varianten), maar dan zou je hetzelfde over C kunnen zeggen als je kijkt naar Assembly.

Er is niks mis met het schrijven in een iets hogere programmeertaal. Sommige functies zullen inderdaad simpeler gedaan kunnen worden, maar vergeet niet dat het gehele programma uiteindelijk groter en complexer is (vaak). Dit geldt zeker voor systemen die met complexe databases werken. Ik denk dat de kunst van het programmeren wel in andere stukken van de broncode nodig zal zijn.

Ik ben het wel met je eens als je trouwens 'kunst' omschrijft als overbodig moeilijk doen ;)
@all:

Uiteraard is het goed deze ontwikkeling, je maakt lekker snel een programma. Ik maak zelf genoeg in .NET en mijn god wat is het lekker simpel om een website te maken tegenwoordig in ASP.NET, 3 klikken en het is klaar. Brilliant!

Maar we krijgen dus nu een probleem van mensen die "weinig" weten van de echte werking van de programmeertaal. Tegenwoordig worden op de meeste scholen niks meer verteld over geheugenblokken e.d. Ik vind dat persoonlijk hartstikke zonde. Terwijl dit 5 jaar geleden nog wel gedaan werd (ik heb het over de meeste MBOs, op HBO+ niveau krijg je er genoeg over mits je je specialiseerd erop).

We krijgen nu een generatie die alleen maar gewend is met hoge programmeertalen te werken. Leuk hoor, maar wie moet de volgende generatie frameworks schrijven? Oke d'r zullen genoeg mensen overblijven, alleen je elimiteert heel veel vaardigheden.

Het is hier ook te zien bij ons bedrijf, steeds minder mensen kennen C en de reut. "Want het kan toch veel sneller met C#?" Ja het kan veel sneller en het is een geweldige oplossing, maar soms heb je pure C nodig... "Maar dat ken ik niet, das stom" :z

En niet alleen C-achtige talen raken "verloren", maar zoals het voorbeeld hierboven.. de "programmeur" eigenlijk de componeur, ziet geen regel SQL code. Alleen blokjes en Next Next Next Finish. En dan is er een bugje, en dat is dan net iets waar je niet bij kan vanaf je hoge stoel, daar zit onze Wizard Progger.

Zoals gezegd is, als er iets onder de motorkap kapot gaat dan zit je.. dan moet je wachten tot MS of een of ander wazig bedrijf een patch uitbrengt.

Misschien wat wazig uitgelegd, mijn excuses daarvoor dan.. Maar in dat opzicht, vind ik het gewoon zonde dat de "kunst" verloren gaat.

En ja ik ben het er nogmaals volledig mee eens dat dit ook leuk werkt en je bent een stuk sneller klaar met developen als je alleen maar op formulier veldjes hoeft te klikken. :z

En nee, ik doe niet alles in ASM :P Maar wil wel het meeste zelf schrijven, alleen al is het omdat het en leuk is en je de meeste controle er over behoudt en de meeste optimalisaties eruit krijgt.
"En nee, ik doe niet alles in ASM Maar wil wel het meeste zelf schrijven, alleen al is het omdat het en leuk is en je de meeste controle er over behoudt en de meeste optimalisaties eruit krijgt."
Mag ook best hoor :) Niemand houdt je tegen! Het geven van een optie wil niet zeggen dat je er ook perse gebruik van moet maken.

"Zoals gezegd is, als er iets onder de motorkap kapot gaat dan zit je.. dan moet je wachten tot MS of een of ander wazig bedrijf een patch uitbrengt."
Dat is gewoon hoe het werkt in de wereld :) Als er iets onder mijn motorkap kapot is dan zal ik ook de garage moeten bellen. In een steeds complexere (digitale) wereld zal het nodig blijven om handelingen eenvoudiger te maken. We kunnen nu eenmaal niet allemaal alles van alles afweten en daarvoor hebben we dit soort abstractie-layers nodig.
Ik laat me ook niet tegenhouden hoor ;)

Maarre... als ik weet hoe een auto in elkaar zit, ga ik het zelf oplossen. Ik koop/maak een nieuw onderdeel en stamp het erin.

Als mijn code niet werkt, wil ik het gewoon zelf oplossen en niet wachten op een of andere onderbetaalde programmeur bij Microsoft in z'n cubicle.
Bij Microsoft werken ze niet in cubicles, en voor zover ik weet betalen ze vrij goed bij Microsoft (alleen de opties heb je niet zo veel aan).
Jij doet nog alles in assembly? :o
'Low-level programming is good for the programmer's soul.' John Carmack
;)
Ik denk ook dat het goed is dat de "kunst" er een beetje af gaat. Alleen zo kunnen we verder komen en kunnen meer mensen er iets mee. Het wiel kennen we nu wel.

Een nadeel is wel dat als er iets onder de motorkap stuk gaat dat je er nu moeilijker bij kunt natuurlijk.
printers en zo zijn goede ontwuikkelingen, maar de kunst om te schrijven in kleitabletten gaat helemaal verloren..

oh. ik nu snap ik eht. je hebt een nostalgie probleem... :P
Afgezien van de vraag 'wat is de kunst van programmeren'?
De kunst van programmeren gaat niet verloren door het invoegen van een datalaag en het uitbreiden van een programmeertaal. Sterker nog, ik durf te stellen dat het de kunst bevorderd.

Bij gebruik van DSL tools kan je een applicatie ontwerpen zonder ook maar ťťn regel code te schrijven. Is dan de kunst van het programmeren verloren? Nee, de kunst is alleen gevolueerd naar het visueel programmeren van applicaties. Het tijdrovende codekloppen is dan voor een groot deel voorbij. Software engineers kunnen zich dan voornamelijk richten op de ťchte business problematiek, in plaats van het debuggen van een pointer welke niet juist is gecodeerd.
Ik heb een eigen Class Generator gemaakt die aan de hand van een Tabel in SQL-Server de sprocs maakt plus de bijbehordende class.

Voor Access wordt er gewerkt met inline SQL in de class.

Scheelt ontzettend veel tijd en de standaard methods zijn vrijwel altijd gelijk dus alleen aangepaste methods moeten nog zelf gemaakt worden.

Verder is LINQ trouwens veelbelovend, al moet je nog wel even wennen aan de QueryTaal aangezien de statements net andersom worden geschreven als is SQL.

Bijv.:

var ids = (
from c in db.Customers, e in db.Employees
where c.City == e.City
select e.EmployeeID )
.Distinct();

Lijkt ingewikkeld maar is na even wennen erg handig aangezien je nu perfect intellie-sence krijgt op je Linq Querys.

Interessante techniek wat denk ik een groot gemak en succes gaat worden.,..
Voor Access wordt er gewerkt met inline SQL in de class.
En daarmee ben je dus meteen weer afhankelijk van het gebruikte SQL dialect.

Snel even overstappen naar een ander database platform is er dus niet bij.

Ik heb in het verleden gewerkt met EOF (Enterprise Objects FrameWorks) en daar kon je zonder code wijzigingen gewoon switchen van Oracle naar Postgress of Openbase.
En daarmee ben je dus meteen weer afhankelijk van het gebruikte SQL dialect.
Wij leveren klanten twee opties: Access of SQL server. Van een bestaande Access applicatie een SQL server applicatie maken is als je SQL geen gebruik laat maken van sprocs in 1 seconde (ConnectieString aanpassen) gebeurd.

Oracle en anderen ondersteunen we niet. In theorie kan Oracle wel gebruikt worden, de SQL gegenereerde code is met het aanpassen van de connectiestring ook om te zetten naar Oracle dus geen probleem.

Het kan dus prima maar is nog nooit gebeurd.
Hoe vaak krijgen jullie dan wel niet een opmerking in de trant van "We gaan wel naar uw buurman die wel *insert non-MS RDBMS* ondersteuning aanbiedt" ? Gebruik maken van Microsoft software is mooi, maar beperk je jezelf niet als bedrijf op deze manier ?
Die opmerking hebben we in zeven jaar ongeveer 0 keer gehad.

Onze klanten maken zich niet druk om de achterliggende techniek maar om het eindresultaat. Als bedrijf kun je het beste resultaat bereiken door je te specialiseren op een paar technieken en dat is wat wij doen.

Het enige wat wel eens is gebeurd is dat er een klant een vraag heeft of we ook php en mysql ondersteunen zodat zijn/haar neefje dan iets aan de site kan aanpassen.

Antwoord is dan simpel, nee, dat ondersteunen we niet.
*Offtopic* Ligt het aan mij of zijn artikelen over producte van MS altijd langer?

Een tijd geleden naar een workshop geweest voor MS Visual Studio. Zelf altijd een java programmeur geweest en dan nog een zonder visual editor, maar was wel even een cultuurschok.

Het gemak waarmee dit programma omspringt met data is echt verbazingwekkend. Drie keer klikken en je hebt een nieuwe "verbinding" met je database. Je leert er niet van programmeren maar snel een applicatie in elkaar zetten gaat goed.

Ben el benieuwd hoe dit datamodel precies gaat werken. Als het voor OO talen nog makkelijker wordt om data op te slaan, zijn er misschien bestwat mensen die wel willen overstappen.
Dat is waar men heen wil en de enige kant waarnaar IDE's door kunnen evolueren lijkt me.
*Offtopic* Ligt het aan mij of zijn artikelen over producte van MS altijd langer?
Het is de grootste leverancier van OSen 8)7
Verder, als je op t.net kijkt zul je eerder zien dat er veel meer over opensource wordt geschreven dan er in verhouding wordt gebruikt.
"*Offtopic* Ligt het aan mij of zijn artikelen over producte van MS altijd langer?"
Het is de grootste leverancier van OSen
jaspero had het over de lengte van de artikelen niet de hoeveelheid er van.
Dat komt misschien omdat de gene die over MS schrijft meer tijd in zijn artikelen stopt er zijn namelijk 20+ nieuws submitters bij tweakers bv.

[Conspiracy theory mode]
Misschien word een of meerdere tweakers nieuws submiter betaalt door de evil M$ :+
[/Conspiracy theory mode]
Verder, als je op t.net kijkt zul je eerder zien dat er veel meer over opensource wordt geschreven dan er in verhouding wordt gebruikt.
Dat is net zo iets als met hybride auto's, dat is omdat de techniek/idee er achter een interessant alternatief is waar men graag over nadenkt,
maar waarschijnlijk/helaas de meeste onder ons niet gebruiken.
Het is de grootste leverancier van OSen
Ja, en?
Verder, als je op t.net kijkt zul je eerder zien dat er veel meer over opensource wordt geschreven dan er in verhouding wordt gebruikt.
T.net wordt maar door een selecte groep gebruikers gelezen. De voorpagina door veel meer gebruikers.
Ik vind het ook opmerkelijk dat de IT-leverancier met het grootste reclame budget ook extra aandacht in alle media (niet alleen Tweakers.nl) krijgt. Blijkbaar is Microsoft ergens goed in wat alle andere IT-bedrijven nog moeten leren...
Ik zit hier op een afdeling als enige developer en dan is een OR Mapper toch wel een verademing, dit na jaren van data layers bouwen/updaten. Mijn keuze ging ook uit naart LLBLGen Pro en dat werkt erg prettig.

Er is volgens mij ooit een beta/alpha/ctp van ObjectSpaces vrijgegeven en daar is WilsonORMapper op gebaseerd.
Ik ben nu reeds al met mijn 5 jaar bezig in VS.NET. En ik heb altijd mijn eigen data layers geschreven, omdat veelal van de OR-mappers korm of slecht geschreven zijn.

DataSets heb ik nooit gebruikt. Gewoon SP's aanmaken en direct aanroepen. Hoe meer er gecached wordt hoe trager je applicatie. Veel 'programmeurs' kunnen niet eens een goede data layer schrijven. Als ze zover zijn dan kunnen zijn naar mijn inziens een beetje gaan beginnen met OR-mappers. Maar tot die tijd moeten ze het maar leren zonder dat soort dingen te doen.
Typisch een geval van NIH ;)

Jij schrijft ook je eigen Grid controls? Of betrek je die van een 3rd party?

Jij roept stored procedures aan, dat kan, het punt is alleen dat het aanroepen van een stored proc een regel kost, maar het gebruiken van de data die terugkomt veel meer regels kost en untyped, tabulair georienteerde code is, terwijl je applicatiecode niet met tabulaire data wil werken maar met objects. Tuurlijk weet jij dat de rows in datatable T customers zijn en dat veld 3 de customerid is en dat customer op rij 15 de customer is die je wilt hebben, maar feitelijk werkt dat veel lastiger, je zit dan nl. untyped met je data te werken waarbij een typo at runtime wordt opgemerkt.

Wat was er zo krom aan de O/R mappers die je gezien hebt en wat is er zo geweldig aan jouw eigen DALs die o.a. de mijne doet verbleken?
Bestaat toch allang jongens.... het heet NHibernate (Hibernate port van Java naar .NET).
Zie: http://www.hibernate.org/343.html
Maar dat werkt niet met programmeurs die al in Visual Studio werken...
:?
Ik snap niet wat je hier bedoeld ? Waarom zou dat niet in VS.NET werken ? Ik gebruik zelf voor een test/hobby projectje NHibernate in VS.NET.

Echter, NHibernate & LLBLGen zijn eigenlijk gebaseerd op 2 verschillende concepten. NHibernate laat je toe om zelf je objecten te schrijven, en je mapping te definieren tussen je objecten en je DB. NHibernate genereert dan at runtime de queries die moeten uitgevoerd worden.
LLBLGen genereert de 'business objecten' zelf.
Iedere O/R mapper (behalve iBatis) genereert zn queries on the fly zelf, er is alleen een verschil in hoe je begint:
1) reverse engineering van je datamodel tot een abstract entity model, op het niveau van NIAM/ORM, daar dan entity classes van maken, die je dan mapt of 1 of meerdere tables/views in je datamodel. LLBLGen Pro volgt dit model, Linq to Sql en Linq to Entities ook.
2) classes maken, dan mappings definieren naar tables/views en of die bestaan of niet, boeit niet zo (als ze niet bestaan worden ze aangemaakt.). Dit model wordt veel toegepast in de wat kalere o/r mappers, dus de o/r mappers met puur een runtime library. At runtime genereren ze dan een subclass (dynamic proxy) per gemapte class, of ze manipuleren na de compilatie de IL code. NHibernate o.a. gebruikt dit model

Feitelijk is er niet echt veel verschil, in die zin dat het technisch gezien verschilt waar je begint, maar in wezen beginnen beide met de entities die je kunt definieren in je problem domain ("Klant", "Order", "Product" etc.), daar relaties tussen legt en met die entities mappings definieert tussen class en table/view.

Zie ook:
http://weblogs.asp.net/fb...-is-the-Domain-Model.aspx
Ik gebruik Ruby in Steel, dat is een RoR plug in voor Visual Studio. RoR heeft een hele fijne ORM mapper als je kan leven met de de niet altijd geweldige performance van Ruby. Productiviteit is echt super.
Ik ben op dit moment met een echt groot project bezig en de performance valt mij 100% mee. Het zit hem vooral in hoe slim jij eventuele performance problemen zelf oplost. Als je dat goed doet, dan komt het prima in orde.
kun je toch hetzelfde doen met typed datasets met de tableadapters ?
De X++ programmeertaal in Microsoft Business Solutions Dynamics (Axapta) heeft dit al sinds het begin, toen Microsoft het nog niet gekocht had en het nog een Deens bedrijf was.
Er zijn plannen om X++ op te nemen in Visual Studio naast de al bestanden programmeertalen. Dan zou dit dus ook mogelijk zijn..
ibatus doet dat toch al..

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True