DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Wat hem tegenhoudt zijn waarschijnlijk die andere developers die fijn vanuit de presentatielaag in de datalaag zitten te frutten.quote:Op dinsdag 31 augustus 2010 11:00 schreef NikkelCobalt het volgende:
Wat houdt je tegen een repository te schrijven?
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Dat inderdaad.quote:Op dinsdag 31 augustus 2010 11:04 schreef Catbert het volgende:
[..]
Wat hem tegenhoudt zijn waarschijnlijk die andere developers die fijn vanuit de presentatielaag in de datalaag zitten te frutten.
Veel 'gelaagdheid' komt er niet bij kijken in dit geval. 
En NikkelCobalt, dat is inderdaad ook een idee. Dan ben ik echter nog meer werk aan het verrichten dan wat ik normaal altijd doe en derhalve ontgaat mij het nut een beetje van deze methoden met LinQ / Entity.
Ook het 'na proberen te bootsen' van échte SQL queries vind ik erg omslachtig, vooral in geval van LIKE en OR operators. Om nog maar te zwijgen over de optimalisatie van de uiteindelijke SQL queries.
Jij hebt het wel over het weakly-typed LINQ taaltje. Je hebt ook nog (Lambda) Expressies waarmee je dan strongly-typed kan query'en. Met alle voordelen daarvan.quote:Op dinsdag 31 augustus 2010 13:44 schreef Tuvai.net het volgende:
[..]
Dat inderdaad.
En NikkelCobalt, dat is inderdaad ook een idee. Dan ben ik echter nog meer werk aan het verrichten dan wat ik normaal altijd doe en derhalve ontgaat mij het nut een beetje van deze methoden met LinQ / Entity.
Overigens zijn de LINQ to SQL query's volgens mij nog wel aardig. Maar die van Entity Framework 1 zijn soms lachwekkend slecht. Nulls met nulls vergelijken en tabellen erbij halen die er niks mee te maken hebben.
Voor de wat simpelere / kleinere projecten vind ik het wel aardig. Bij serieuze projecten zet ik er ook mijn vraagtekens bij. Maar het zou vast wel richting de kant van de betere ORM's op gaan, en die worden toch al in veel serieuze applicaties / websites gebruikt.
Wat ook wel leuk aan LINQ is dat je niet alleen databases kan query'en, maar ook bv. een List.
Nope, met die Strong Typed versie inclusief Lambda Expressions ben ik ook bezig. Maar ik vind het nog steeds vrij omslachtig. Om een heel goed voorbeeld te noemen: Ik heb een heel groot overzicht (een GridView) met een heleboel velden daarin, en op vrijwel al die velden kan 'gefilterd' worden. Die filters en de daarmee corresponderende velden bestaan uit allerlei DropdownLists, Textboxes, Checkboxes, enzovoorts. Nu heb ik om die GridView te vullen altijd het volgende stukje code (effe namen aangepast voor duidelijkheid):
Oftewel een paar dingen kan ik in deze 'where clausules' al verwerken, met name de filters/selecties die altijd van toepassing zijn. Maar om bijvoorbeeld al die variabele filterwaarden er in te verwerken, krijg ik allemaal stukjes code als volgt:
Terwijl ik met mijn normale methode (dus SQL -> DAL -> BLL -> Presentatie) in mijn BL-classes allerlei static methods klaar zet waarmee allerlei selecties en filters verricht kunnen worden, denk dan aan methoden als:
Maar goed, voor kleine projectjes zal dit inderdaad handig zijn om snel interactie met je database te hebben vanuit je applicatie. Maar voor grotere projecten zou ik nooit voor een dergelijke aanpak kiezen.
Maar ik vind het nog steeds vrij omslachtig. Om een heel goed voorbeeld te noemen: Ik heb een heel groot overzicht (een GridView) met een heleboel velden daarin, en op vrijwel al die velden kan 'gefilterd' worden. Die filters en de daarmee corresponderende velden bestaan uit allerlei DropdownLists, Textboxes, Checkboxes, enzovoorts. Nu heb ik om die GridView te vullen altijd het volgende stukje code (effe namen aangepast voor duidelijkheid):| 1 2 3 4 5 | IQueryable<Dinges> ResultsetQuery = from tDinges in Entities.Dinges where tDinges.Veld1 == StrongTypedWaarde1 where tDinges.Veld2 == StrongTypedWaarde2 select tDinges; |
| 1 2 3 4 5 | { ResultsetQuery = ResultsetQuery.Where(tDinges => tDinges.Veld3.Contains(TextboxVoorFilter3.Text)); } if (!String.IsNullOrEmpty(TextboxVoorFilter4.Text)) { ResultsetQuery = ResultsetQuery.Where(tDinges => tDinges.Veld4.Contains(TextboxVoorFilter4.Text)); } |
| 1 |
| 1 |
Complexe where-clauses kunnen toch ook gewoon in linq?
| 1 2 3 4 5 6 7 8 9 10 | where matches(filter1, x.Veld1) where matches(filter2, x.Veld2) ... select x bool matches(string filter, string value) { return string.IsNullOrEmpty(filter) || value.Contrains(filter); } |
Mja, noem het een kwestie van smaak, maar ik vind het een heel gedoe allemaal voor simpele handelingen. Ik prefereer liever mijn eigen, kinderlijk eenvoudige methode waar er met een Stored Procedure gecommuniceerd wordt, waar dan weer een SQL query in staat waar ik gewoon LIKE operators e.d. kan gebruiken.quote:Op woensdag 1 september 2010 12:44 schreef OEM het volgende:
Complexe where-clauses kunnen toch ook gewoon in linq?
[ code verwijderd ]
Om nog maar te zwijgen over het feit dat mijn codebehinds en BLLS nu bulken van 'Queries' en Lambda Expressions'. Mij is geleerd om databasezaken in de database te houden.Ook zullen er straks veel dingen in dit project gedaan moeten worden waar normaliter echt 'Dynamic SQL' voor gebruikt wordt, en zal er met Cross Database Queries gewerkt moeten worden. Daar zie ik erg tegenop met LINQ / Entity Framework.
[ Bericht 7% gewijzigd door Tuvai.net op 01-09-2010 13:52:59 ]
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)
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)
hula
Ik denk dat ie exact de essentie door heeft. Als je linq2sql gaat gebruiken in de presentatielaag wordt het een grote ellende die we nog kennen van sql queries in pagina's of de datasets variant ervan (1 op 1 kopieen van tabellen).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)
Linq is best handig, maar linq2sql hoort in je dal thuis, niet in je gui
.
quote:Op dinsdag 31 augustus 2010 21:14 schreef Tuvai.net het volgende:
Nope, met die Strong Typed versie inclusief Lambda Expressions ben ik ook bezig.
[ code verwijderd ]
Oftewel een paar dingen kan ik in deze 'where clausules' al verwerken, met name de filters/selecties die altijd van toepassing zijn. Maar om bijvoorbeeld al die variabele filterwaarden er in te verwerken, krijg ik allemaal stukjes code als volgt:
[ code verwijderd ]
| 1 2 3 4 5 | IQueryable<Dinges> ResultsetQuery = from tDinges in Entities.Dinges where (StrongTypedWaarde1 == null || tDinges.Veld1 == StrongTypedWaarde1 ) where (StrongTypedWaarde2 == null || tDinges.Veld2 == StrongTypedWaarde2 ) select tDinges; |
Persoonlijk kies ik voor views wanneer LINQ queries te lang worden trouwens . Ook horen ze inderdaad thuis in de DAL (of een repository). Wel oppassen voor deferred execution.
. Ook horen ze inderdaad thuis in de DAL (of een repository). Wel oppassen voor deferred execution.
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.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 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 databasequote: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.
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.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.
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.
hula
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.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.
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.
Dan kan ik net zo goed met mijn eigen DAL class verder gaan die dat al doet.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.
'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.quote:Als jij ontzettend veel variabele parameters hebt wordt het een ander verhaal maar dan moet je sowieso veel code schrijven, ook zonder LINQ.
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
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
Dit pleit overigens toch juist voor LINQ(toSQL)?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.
hula
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?
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?
NIEUW: Foto's!
Bij sommige projecten zul je zelfs wel moeten.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.
....
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.
je moet nu oAuth gebruiken als je de api van twitter wilt gebruiken.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?
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/
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.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.
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.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.
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
