Microsoft .NET - deel 1

quote:

Op woensdag 1 september 2010 15:11 schreef NikkelCobalt het volgende:
Volgens mij geef je zelf al deels het antwoord op je problemen: meer gebruik maken van de database: Aan views en functies gedacht? Die herkent LINQtoSQL namelijk gewoon.

En verder denk ik dat je gewoonweg te weinig met LINQ hebt gedaan om er iets zinnigs over te zeggen. Situaties die je oplost met directe queries kun je net zo goed oplossen met LINQ(tosql).

Absoluut zijn er situaties waarin LINQ minder goed van toepassing is, maar de situaties die jij beschrijft noem ik niet direct problematisch. Het kostte mij overigens ook wel tijd om LINQ en LINQtoSQL onder de knie te krijgen

Om nog even een concreet te noemen: ik heb nu in een project (op LINQtoSQL) ook iemand meegemaakt die nog nooit van LINQ heeft gehoord. ASP.NET classic project was het, en die ging lekker allemaal stored procedures maken ipv een LinqDataSource gebruiken. Daar word ik dan weer wat minder vrolijk van

Wat ik overigens erg leuk vind aan LINQtoSQL is de databasereflectie die je standaard kunt doorlopen. (Hoewel de gebruikssituatie wel weer vrij specifiek is)

Ik ben ben inderdaad geen meester als het op LINQ aankomt nee, maar ik heb er genoeg van gezien en mee geklooid om er een oordeel over te scheppen. Het hele LINQ gebeuren is voor mij gewoon een ander werkwijze voor iets dat ik al jarenlang op een, in mijn mening veel mooiere en snellere, eigen manier doe. Ik ben het de afgelopen 2 dagen actief aan het gebruiken en heb eens voor te proberen op een kopie van een eigen project alles functioneel omgezet van mijn eigen methode naar LINQ. De Codebehinds van mijn WebForms zijn nu afzichtelijk en groot, en het ophalen van gegevens duurt gewoon langer (weliswaar nog maar milliseconden op duizenden records, maar toch). De hele manier van werken met LINQ e.d. spreekt mij gewoon niet aan. Als ik met LINQ werk krijg ik een beetje het gevoel dat de database een ruwe blok met platte gegevens is, waarvan ik de eindjes pas op applicatieniveau aan elkaar begin te knopen.

Ik vind het mooi hoe je met ADO.NET Entities d.m.v. een paar keer 'Volgende' klikken een heel model met daarin meerdere 'Business Objects' kunt genereren in een paar seconden tijd. Voor een klein website`je met een gastenboek waar ik alleen een tabel met reacties uit hoef te lezen, lijkt LINQ mij ideaal. Maar voor grote applicaties waar vaak met relationele data wordt gewerkt en je soms wel tot 6 niveau's diep moet 'joinen' in je queries, vind ik het onpraktisch. De hele manier van het aanspreken / benaderen / ophalen / koppelen van de Entities vind ik gewoon lomp.

quote:

Op woensdag 1 september 2010 20:48 schreef Tuvai.net het volgende:

[..]

Ik ben ben inderdaad geen meester als het op LINQ aankomt nee, maar ik heb er genoeg van gezien en mee geklooid om er een oordeel over te scheppen. Het hele LINQ gebeuren is voor mij gewoon een ander werkwijze voor iets dat ik al jarenlang op een, in mijn mening veel mooiere en snellere, eigen manier doe. Ik ben het de afgelopen 2 dagen actief aan het gebruiken en heb eens voor te proberen op een kopie van een eigen project alles functioneel omgezet van mijn eigen methode naar LINQ. De Codebehinds van mijn WebForms zijn nu afzichtelijk en groot, en het ophalen van gegevens duurt gewoon langer (weliswaar nog maar milliseconden op duizenden records, maar toch). De hele manier van werken met LINQ e.d. spreekt mij gewoon niet aan. Als ik met LINQ werk krijg ik een beetje het gevoel dat de database een ruwe blok met platte gegevens is, waarvan ik de eindjes pas op applicatieniveau aan elkaar begin te knopen.

Ik vind het mooi hoe je met ADO.NET Entities d.m.v. een paar keer 'Volgende' klikken een heel model met daarin meerdere 'Business Objects' kunt genereren in een paar seconden tijd. Voor een klein website`je met een gastenboek waar ik alleen een tabel met reacties uit hoef te lezen, lijkt LINQ mij ideaal. Maar voor grote applicaties waar vaak met relationele data wordt gewerkt en je soms wel tot 6 niveau's diep moet 'joinen' in je queries, vind ik het onpraktisch. De hele manier van het aanspreken / benaderen / ophalen / koppelen van de Entities vind ik gewoon lomp.

LINQ to entities is even wennen, maar ik vind het juist een mooie manier om tegen je database aan te programmeren. Er wordt een conceptueel model van je database gegenereerd, dat houdt bijvoorbeeld in dat meer op meer relaties geabstraheerd worden. Ook subtypes/overerving in je database wordt netjes afgehandeld. Verder kun je ook gebruik maken van code templates, waarbij je heel makkelijk code kunt genereren op basis van de metadata van je database

quote:

Op woensdag 1 september 2010 20:48 schreef Tuvai.net het volgende:
Maar voor grote applicaties waar vaak met relationele data wordt gewerkt en je soms wel tot 6 niveau's diep moet 'joinen' in je queries, vind ik het onpraktisch.

Ja en m.i. zit daar je denkfout. LINQ betekend niet dat je al het werk van de database door je .NET applicatie moet laten oplossen.

Je kunt die 6 niveau diepe join query gewoon in een stored procedure/view/functie stoppen. Als jij ontzettend veel variabele parameters hebt wordt het een ander verhaal maar dan moet je sowieso veel code schrijven, ook zonder LINQ.

Ik vind overigens de uitbreidbaarheid en flexibiliteit van Entity Framework een beetje tegenvallen tov LINQ. De queries daarentegen zijn wel mooier, dit vind ik het grootste nadeel van LINQ. Maar dat is goed op te vangen met diezelfde views/sp's /functions.

quote:

Op vrijdag 3 september 2010 19:11 schreef NikkelCobalt het volgende:
Ja en m.i. zit daar je denkfout. LINQ betekend niet dat je al het werk van de database door je .NET applicatie moet laten oplossen.

LINQ in lokt dat wel een beetje uit vind ik, en veel mensen doen dat ook. Noem me ouderwets, maar ik vind dat mijn database moet dienen als de plek waar alle gegoochel met data plaats moet vinden, en die mij een kant en klare, bruikbare output / resultset retourneert waar ik in mijn applicatie direct mee aan de slag kan. Op databaseniveau gaat dat gewoon sneller en gemakkelijker. Wat ik vaak zie in applicaties die bulken met LINQ, is dat er hele grove resultsets van database naar applicatie geslingerd worden, die vervolgens op applicatieniveau pas gesorteerd, gegroupeerd, gelimiteerd (bijv. ingedeeld in pagina's met een beperkt aantal items) en/of geabstraheerd worden.

Ik bedoel maar, je kunt er zeker mooie applicaties mee maken waar je ook nog goed rekening houdt met snelheid, performance en logica. Maar LINQ spoort mijns inziens wel aan om het toch lekker op de quick 'n dirty manier te doen, omdat het oh zo gemakkelijk is om 'queries' direct tegen je database aan te gooien.

quote:

Op vrijdag 3 september 2010 19:11 schreef NikkelCobalt het volgende:
Je kunt die 6 niveau diepe join query gewoon in een stored procedure/view/functie stoppen.

Dan kan ik net zo goed met mijn eigen DAL class verder gaan die dat al doet.

quote:

Als jij ontzettend veel variabele parameters hebt wordt het een ander verhaal maar dan moet je sowieso veel code schrijven, ook zonder LINQ.

'Dynamic SQL' in Stored Procedures is helemaal niet veel werk. In grove lijnen is het gewoon jouw 'normale' SQL query maar dan in een NVARCHAR variabele gestopt, waar nodig eventuele 'statische' stukken afgevangen met andere variabelen. Ik gebruik dit vooral veel in enterprise systemen waar je één database hebt met applicatiegegevens (gebruikers, rechten, enz.) en per klant / omgeving een database hebt met daadwerkelijke data. In LINQ / met Lambda Expressions is dit aanzienlijk meer werk dan even een query 'dynamisch maken', om nog maar te zwijgen over complexiteit. Maar goed, dat laatste is weer een kwestie van smaak.

Ik ben hier niet om je wel/niet te overtuigen van LINQ hoor Maar ik zou het jammer vinden (nouja, je hebt mij er niet mee natuurlijk ) als je bepaalde dingen links laat liggen op basis van een eerste indruk.

In grote applicaties gebruik ik zelf liever geen LINQ omdat ik meer controle wil hebben over het aantal queries dat wordt uitgevoerd. Want LINQ gebruiken en de profiler op je database loslaten is als een continue stroom aan overlijdensberichten.

Op internet zijn weinig goede voorbeelden over LINQ te vinden, ben ik met je eens. Maar dat heb je sowieso met .NET en meer geavanceerde zooi. Om nog maar niet te spreken van die Indiërs die complete goochelcode artikelen schrijven. Brrr

quote:

Noem me ouderwets, maar ik vind dat mijn database moet dienen als de plek waar alle gegoochel met data plaats moet vinden, en die mij een kant en klare, bruikbare output / resultset retourneert waar ik in mijn applicatie direct mee aan de slag kan.

Dit pleit overigens toch juist voor LINQ(toSQL)?

Iemand hier trouwens ervaring met oAuth en Twitter?

Ik heb (lees: had) op m'n site een lijstje met m'n laatste tweets staan.
Simpelweg door Basic Authentication.

Maar nu, sinds half augustus geloof ik, moet je gebruik maken van oAuth.
En zo'n beetje alles wat ik daar over tegen kom, houd in dat je naar de twitter site wordt gestuurd om in te loggen.
Dat is natuurlijk niet de bedoeling.

Ik wil gewoon een lijst met mijn laatste 20 tweets ofzo, en die tonen. Meer niet.
Iemand enig idee hoe ik dat nu aan ga pakken? Of waar ik verder kan zoeken?

quote:

Op vrijdag 3 september 2010 19:11 schreef NikkelCobalt het volgende:

[..]

Ja en m.i. zit daar je denkfout. LINQ betekend niet dat je al het werk van de database door je .NET applicatie moet laten oplossen.

Je kunt die 6 niveau diepe join query gewoon in een stored procedure/view/functie stoppen.
....

Bij sommige projecten zul je zelfs wel moeten.

Ik heb DBAdmins meegemaakt waar ik uitsluitend rechten op views en sprocs kon krijgen. (Wat opzich ook goed te verdedigen is)

Op z'on moment maak ik liever mijn eigen class en laat EF links liggen.

En voor mijn eigen classes heb ik een generator gemaakt met myGeneration dus dat is ook maar een paar tellen werk.

quote:

Op dinsdag 7 september 2010 22:53 schreef Cryothic het volgende:
Iemand hier trouwens ervaring met oAuth en Twitter?

Ik heb (lees: had) op m'n site een lijstje met m'n laatste tweets staan.
Simpelweg door Basic Authentication.

Maar nu, sinds half augustus geloof ik, moet je gebruik maken van oAuth.
En zo'n beetje alles wat ik daar over tegen kom, houd in dat je naar de twitter site wordt gestuurd om in te loggen.
Dat is natuurlijk niet de bedoeling.

Ik wil gewoon een lijst met mijn laatste 20 tweets ofzo, en die tonen. Meer niet.
Iemand enig idee hoe ik dat nu aan ga pakken? Of waar ik verder kan zoeken?

je moet nu oAuth gebruiken als je de api van twitter wilt gebruiken.

Alternatief, maak de juiste zoekopdracht aan en gebruik de rss hiervan om je tweets op je eigen site te zetten.

RSS lees je heel makklijk in met http://aspnetrsstoolkit.codeplex.com/

quote:

Op vrijdag 10 september 2010 16:43 schreef HansvD het volgende:

[..]

Bij sommige projecten zul je zelfs wel moeten.

Ik heb DBAdmins meegemaakt waar ik uitsluitend rechten op views en sprocs kon krijgen. (Wat opzich ook goed te verdedigen is)

Op z'on moment maak ik liever mijn eigen class en laat EF links liggen.

En voor mijn eigen classes heb ik een generator gemaakt met myGeneration dus dat is ook maar een paar tellen werk.

Als ik in teamverband werk, dan geef ik aan een dergelijke werkwijze ook de voorkeur. Iedereen gewoon zijn eigen rol, klaar. Voor kleine projectjes kun je het best permiteren om 'alles' te doen (van front-end tot back-end / database), maar bij grotere projecten met meerdere manusjes van alles te werken, resulteert in een knoeiboel.

Vandaar ook mijn eerdere opmerking; ik ga vanuit applicatie / DAL-niveau graag uit van Stored Procedures e.d. waar ik alleen maar mijn parametertjes naar toe hoef te sturen, en waar alle werk plaats vindt. Werkt doorgaans ook veel sneller en prettiger als je bijvoorbeeld één persoon hebt die de hele database opzet, terwijl een ander de applicatie zelf bouwt en gebruik maakt van de middelen die de databaseontwerper klaar zet.

quote:

Op vrijdag 10 september 2010 23:16 schreef Tuvai.net het volgende:

[..]

Als ik in teamverband werk, dan geef ik aan een dergelijke werkwijze ook de voorkeur. Iedereen gewoon zijn eigen rol, klaar. Voor kleine projectjes kun je het best permiteren om 'alles' te doen (van front-end tot back-end / database), maar bij grotere projecten met meerdere manusjes van alles te werken, resulteert in een knoeiboel.

Vandaar ook mijn eerdere opmerking; ik ga vanuit applicatie / DAL-niveau graag uit van Stored Procedures e.d. waar ik alleen maar mijn parametertjes naar toe hoef te sturen, en waar alle werk plaats vindt. Werkt doorgaans ook veel sneller en prettiger als je bijvoorbeeld één persoon hebt die de hele database opzet, terwijl een ander de applicatie zelf bouwt en gebruik maakt van de middelen die de databaseontwerper klaar zet.

En juist dan is linq heel erg handig. Krijg je mooi je strong typed resultaten terug van je sp's en kun je ze gelijk uitlezen.

Verder heb ik een stukje software genereert dat automatisch unit tests maakt van DBML klasses. Veranderd een parameter / SP output? --> Test gaat op de bek, terwijl testen automatisch gegeneerd worden.

Ideaal

quote:

Op zaterdag 11 september 2010 20:54 schreef Wijnbo het volgende:

[..]

En juist dan is linq heel erg handig. Krijg je mooi je strong typed resultaten terug van je sp's en kun je ze gelijk uitlezen.

Verder heb ik een stukje software genereert dat automatisch unit tests maakt van DBML klasses. Veranderd een parameter / SP output? --> Test gaat op de bek, terwijl testen automatisch gegeneerd worden.

Ideaal

Heb met myGeneration hetzelfde gemaakt.

Ik ontwerp de tabellen en myGen maakt de sprocs, de classes, de unittests en een kale lijst / detail pagina in weergave en edit mode.

De ene keer gebruik ik dus myGen, de andere keer EF.

quote:

Op vrijdag 10 september 2010 16:43 schreef HansvD het volgende:

[..]

Bij sommige projecten zul je zelfs wel moeten.

Ik heb DBAdmins meegemaakt waar ik uitsluitend rechten op views en sprocs kon krijgen. (Wat opzich ook goed te verdedigen is)

Op z'on moment maak ik liever mijn eigen class en laat EF links liggen.

En voor mijn eigen classes heb ik een generator gemaakt met myGeneration dus dat is ook maar een paar tellen werk.

Eerlijk gezegd snap ik niks van je reactie. Je zegt dat je in sommige gevallen met een bepaalde db-user alleen toegang hebt tot views en sp's (snap ik). Maar alsnog gebruik je een ORM (myGeneration in dit geval), alleen laat je de EF ORM links liggen.

Zeg je nu iets te beamen of juist niet? Bepaalde reden om het EF ORM niet te gebruiken?

Overigens ben ik niet bekend met myGeneration.

quote:

Op dinsdag 14 september 2010 09:43 schreef NikkelCobalt het volgende:

[..]

Eerlijk gezegd snap ik niks van je reactie. Je zegt dat je in sommige gevallen met een bepaalde db-user alleen toegang hebt tot views en sp's (snap ik). Maar alsnog gebruik je een ORM (myGeneration in dit geval), alleen laat je de EF ORM links liggen.

Zeg je nu iets te beamen of juist niet? Bepaalde reden om het EF ORM niet te gebruiken?

Overigens ben ik niet bekend met myGeneration.

Ik heb ooit mijn eigen classes en sprocs ontworpen, dat deed ik vroeger met de hand.

myGeneration is een tool waarmee je vrij gemakkelijk aan de hand van je database model je classes en overige veelgebruikte code kunt genereren.

Dus mijn voordeel: mijn eigen ontworpen classes, sprocs, unittests en management pagina's genereer ik nu in 1 seconde, ik zit dus niet vast aan de werking van een ORM maar ik gebruik myGeneration om mijn eigen code te genereren.

Of om uit hun eigen tekst te quoten:

Template Based Code Generator Supporting Four Template Languages - JScript, VBScript, C# and VB.NET
Ability to Create Your Own Embedded User Interface in your Templates

Dat deel gebruik ik dus.


Zie: http://www.mygenerationsoftware.com/

Ik weet wat MyGeneration is, heb er alleen nog nooit mee gewerkt. Maar heb jij wel in de gaten wat een ORM is? En dat MyGeneration ook een ORM is? En LINQToSQL ook? En Entity Framework ook?

Ik bedoel, wat heb je nodig als je EF 4.0 hebt (EF4 biedt ook de mogelijkheid zelf die code generation templates te maken)

Overigens ben ik zelf altijd een beetje anti 3rd party software. En dan voornamelijk zulke tools (bv. object databases, wat een drama).

quote:

Op dinsdag 14 september 2010 13:10 schreef NikkelCobalt het volgende:
Ik weet wat MyGeneration is, heb er alleen nog nooit mee gewerkt. Maar heb jij wel in de gaten wat een ORM is? En dat MyGeneration ook een ORM is? En LINQToSQL ook? En Entity Framework ook?

Ik bedoel, wat heb je nodig als je EF 4.0 hebt (EF4 biedt ook de mogelijkheid zelf die code generation templates te maken)

Overigens ben ik zelf altijd een beetje anti 3rd party software. En dan voornamelijk zulke tools (bv. object databases, wat een drama).

Ik kan vast in EF 4 ook mijn eigen classes e.d. genereren in de stijl zoals ik dat wil.

Ik gebruik myGeneration sinds .net 2 (of 1.1 dat weet ik niet meer) dus die templates had ik al.
En of dat ook ORM is, dat zal dan wel. Ik vind het in EF allemaal minder helder dan mijn eigen classes.

Mijn classes bestaan gewoon uit wat properties en methodes als getItem, save, delete en getitems. In die methodes roep ik mijn sprocs aan, zo doe ik dat sinds .net 1 en op een bepaald moment ben ik myGen gaan gebruiken omdat ik daar mijn classes makkelijk mee kon genereren.

En dat bevalt me vooral bij grote projecten veel beter als EF.

Ieder zijn keuze.

quote:

Op dinsdag 14 september 2010 13:54 schreef HansvD het volgende:
Ieder zijn keuze.

Absoluut

Weet iemand een goed boek voor C# (over gestapt van VB nadat ik hier systematisch werd geterroriseerd ) voor redelijke beginners?
Die van O'Reilly bevalt me wel maar ben uiteraard benieuwd naar jullie ervaringen…

Wat is trouwens het nut van de curly braces t.o.v. bijv. VB?

quote:

Op vrijdag 24 september 2010 15:54 schreef Ker_Plunk het volgende:
Weet iemand een goed boek voor C# (over gestapt van VB nadat ik hier systematisch werd geterroriseerd ) voor redelijke beginners?
Die van O'Reilly bevalt me wel maar ben uiteraard benieuwd naar jullie ervaringen…

Wat is trouwens het nut van de curly braces t.o.v. bijv. VB?

Als je VB.Net al kent zou ik geen boek kopen om C# te leren. Zoveel verschil zit er niet tussen.

Het principe van .net daar gaat het om , niet om een ; of een {

En online kun je met converters je vb ook nog omzetten. bv via: http://www.developerfusion.com/tools/convert/vb-to-csharp/

Wij kunnen het hier gelukkig zelf bepalen en zo doet de 1 vb.net en de ander c#

quote:

Op vrijdag 24 september 2010 16:13 schreef HansvD het volgende:

[..]

Als je VB.Net al kent zou ik geen boek kopen om C# te leren. Zoveel verschil zit er niet tussen.

Het principe van .net daar gaat het om , niet om een ; of een {

En online kun je met converters je vb ook nog omzetten. bv via: http://www.developerfusion.com/tools/convert/vb-to-csharp/

Wij kunnen het hier gelukkig zelf bepalen en zo doet de 1 vb.net en de ander c#

Ben een beginnend programmeur/back-end devver dus wil wel een boek, gaat toch via de zaak Die converter gebruik ik ook regelmatig.

grappig eigenlijk. Ik moet hier VB.NET doen gezien management denkt dat iedereen die VBA in excel heeft gebruikt kan VBen en dat er dus een grotere knowhow van VB is waardoor we daarin moeten ontwikkelen.

Maargoed, ga maar eens een paar vanuit PLC doorgegroeide figuren uitleggen dat VBA en VB.NET niet echt veel met elkaar te maken hebben en dat c# niet eng is. Overigens ook zoals HansvD aangeeft, het gaat om het zinnig gebruiken van het framework. Of dat tussen if then endif of if() {} staat maakt daarin niets uit. Is een weekje wennen aan syntax en heel af en toe eens googlen hoe die vb syntax nou naar c# moest.

Er zitten minieme verschillen tussen C# en VB.NET. In het ergste geval is het een kwestie van een paar dagen je werkwijze aanpassen, als je van VB naar C# (of andersom) gaat. Een boek puur voor die overstap lijkt me vrij overbodig.

Ikzelf heb een enorme hekel aan VB.NET, het wilt naar mijn mening een beetje lijken op een letterlijke taal, al dan niet met een splaakgeblek. Ik vind C# gewoon veel overzichtelijker, juist vanwege de accolades. Echt het enige dat ik in C# mis dat VB wél heeft, is de 'With' operator. Handig als je van één object een hele rits aan properties wilt instellen.

Het sluiten van je database, is dat alleen nuttig vanwege het dataverkeer en voor databases zoals access die moeite heeft met meerdere connectie's?
Ik gebruik het namelijk nooit…

quote:

Op maandag 27 september 2010 16:49 schreef Ker_Plunk het volgende:
Het sluiten van je database, is dat alleen nuttig vanwege het dataverkeer en voor databases zoals access die moeite heeft met meerdere connectie's?
Ik gebruik het namelijk nooit…

Vind je dat dan niet reden genoeg?

Ik zit nu ook weer bij een bedrijf waar ze de Close method niet kennen,laat staan try/catch/finally, laat staan using. En zo staat regelmatig systeembeheer weer te klagen dat de database het niet trekt.

quote:

Op maandag 27 september 2010 19:17 schreef OEM het volgende:

[..]

Vind je dat dan niet reden genoeg?

Ik zit nu ook weer bij een bedrijf waar ze de Close method niet kennen,laat staan try/catch/finally, laat staan using. En zo staat regelmatig systeembeheer weer te klagen dat de database het niet trekt.

Nog irritanter is wanneer men met bestanden / IO gaat werken en de streams niet doet sluiten. Zit je wat te etteren met een bestand dat steeds 'in gebruik' is.

quote:

Op maandag 27 september 2010 16:49 schreef Ker_Plunk het volgende:
Het sluiten van je database, is dat alleen nuttig vanwege het dataverkeer en voor databases zoals access die moeite heeft met meerdere connectie's?
Ik gebruik het namelijk nooit…

Jah tof man. En dan heb je een keer iets in een loopje staan, en heb je 5K open connecties. Woehoe.

quote:

Op dinsdag 28 september 2010 08:02 schreef Wijnbo het volgende:

[..]

Jah tof man. En dan heb je een keer iets in een loopje staan, en heb je 5K open connecties. Woehoe.

Easy
Jullie vergeten af en toe dat ik nog een 'beginner' ben, dus daarom vraag ik dit soort dingen

Nou 'beginner' . Alles dat een beperkte resource is (file I/O, db connecties etc.) altijd met respect en mate behandelen.

DB connecties niet meer openen dan je nodig hebt, overweeg of die connectie open moet blijven gedurende de lifetime van je programma of maakt het niet uit dat je opnieuw connect als je de db nodig hebt. Die afwegingen zijn allemaal afhankelijk van je probleem.

Ik heb een database connectie en de bijbehorende sql in de code-behind van een overzichtspagina (met gridview) gezet. Dit deed ik normaal op de pagina zelf.
Nu wil de gridview een DataSourceID hebben… ik heb de gedefineerde connectie string gebruikt maar krijg de foutmelding 'The DataSourceID of 'grdView' must be the ID of a control of type IDataSource. A control with ID 'conWebsite' could not be found.'

Dan moet je een datasource toevoegen (die gebruik maakt van de connectionstring en de query), of je kent via de code-behind de eigenschap Datasource toe met een collectie van items.

Allereerst: cool topic. Ik ben student en leer op school eigenlijk alleen Java, de stap naar C# is echter zo gemaakt. Vandaar ook even deze twee tips voor iedereen:

Allereerst the yellow-book van Rob Miles, een supergave hoogleraarnerd uit Hull die probeert zoveel mogelijk java-studenten over te halen het .NET framework (ook) te adopteren d.m.v. o.a. dit boek. Gratis te downloaden via: http://www.robmiles.com/c-yellow-book/ heb ik zelf heel veel aan gehad en natuurlijk bruikbaar voor iedereen.

En ben bovendien met gratis ontwikkelsoftware (legaal) in aanraking gekomen via deze facebookpage:

http://www.facebook.com/microsoftnlstudents je moet wel even "Liken" geloof ik, maar dan krijg je een link naar een bepaald microsoft programma waar je o.a. allerlei developmentproducten gratis kunt downloaden.