Dat is de reden waarom ik zou houd van het ZZP bestaan

Ik zet zo min mogelijk de wekker, want dat zorgt alleen voor een slecht humeur

Gelukkig kan ik 90% van mijn werkzaamheden uitvoeren op het moment dat ik mij geroepen voel

Geen noodzaak voor de wekker dus

Niet helemaal waar. Ik probeer zoveel mogelijk over te nemen (liefst aan te roepen in de Dapper code), maar wil wel graag mijn DB wrapper behouden. Die heeft een aantal zeer handige dingetjes die ik gebruik. Dapper supporte out-of-the box ook nog niet de mogelijkheid op basis van een datareader een object te mappen (je moest altijd de query naar dapper sturen en hij handelde het af), dat is iets wat ik via een kleine functie heb toegevoegd om te voorkomen dat ik grote blokken moest copy-pasten of moest herschrijven

Wat weerhoud je ervan om een overload te definieren (kan prima met extension methods) die voor jou je geliefde ENUMs afhandeld op de manier die jij wilt?

Die staat op mijn lijstje. Probleem is alleen dat ik bang ben daar zoveel tijd in te moeten steken dat het misschien sneller is om het toch zelf voor een deel te bouwen.
Wat betreft die opcodes, dat zou je zo kunnen herschrijven naar calls op de Reflection API. Alleen is dit efficiënter. Je hebt wel het gevoel dat je assembly aan het lezen bent, dat wel.. Maar het is niet dat er Reflection.emit gebruikt word uit noodzaak oid. (zover ik kan nagaan)
Maar waarom wil je niet integraal Dapper gebruiken, en ben je aan het proberen om er dingen uit te trekken voor in je eigen project? Kijk als jij het zelf wilt gaan bouwen, be my guest, maar onderschat niet hoeveel tijd er in Dapper zit.
Omdat in projecten ik al gebruik maak van mijn eigen library. Delen van Dapper kunnen handig zijn om te gebruiken in die library. Dat is dus waar ik naar op zoek ben. Heel Dapper herschrijven is niet mijn doel, maar stukken gebruiken in mijn eigen library is wel iets wat ik probeer na te streven.
Overigens is mijn eigen library al onderdeel van mijn toolbelt sinds 2007. Sinds dat moment groeit mijn eigen library in mogelijkheden en zag ik nu een moment om wat extra mogelijkheden er bij te voegen

Een deel van de mogelijkheden zijn niet meer nodig als je bepaalde ORM/libraries gebruikt, maar als je rechtstreeks op data werkt zijn ze zeker nog nuttig (zo heeft mijn library een charmante oplossing voor dbnull die netjes een null teruggeeft en hoefde je niet meer met GetOrdinal te werken maar kon je direct op basis van kolomnaam data ophalen). Dus ik ben niet vanaf 0 begonnen
Waar ik eigenlijk naar op zoek was is het stukje code dat een object omzet in een array van DbParameters. Als ik dat stukje weet te "isoleren" kan ik die aanroepen om de DbParameters te creeeren. Ben al een redelijk stuk door de code gekomen, maar heb nog steeds niet helemaal gevonden waar nu precies die DbParameters gemaakt worden. Inmiddels heb ik het principe zelf gerepliceerd in mijn eigen code (middels reflection) en dat lijkt prima te werken.
(daar support ik zelfs al attributen in om te bepalen hoe bepaalde properties moeten worden behandeld)En waarvoor betaald jou klant je nu? om een business probleem op te lossen? of om data-acces opnieuw uit te vinden?
Mijn klant betaalt (in principe) voor beide. Ze willen namelijk ook dat het op een efficiente manier gebeurt. Als ik nu de hele handel naar dapper herschrijf kost het ze ook geld.
Overigens betaald
niemand mij voor
dit project. Dit is eigenlijk meer mijn eigen kindje wat ik groot probeer te brengen. Toevallig zet ik hem wel in bij meerdere klanten, maar niemand draagt de ontwikkelkosten. Daarnaast zet ik het bij meerdere klanten in, dus is het lastig om de kosten bij 1 klant te leggen.
Het project is gestart in mijn vrije tijd en ik zoek steeds dingetjes om uit te breiden. De enige momenten dat ik declareer bij klanten is als klanten specifieke wensen hebben waar ik niet in voorzien had. Zo heb ik ooit wat extra (declarabele) uurtjes geinvesteerd om de library Oracle te laten supporten. Dit kosten enkele uurtjes omdat ik de Oracle calls moest inbouwen (en de afwijkingen moest afvangen), maar scheelde een hoop tijd omdat we makkelijk konden schakelen tussen Oracle, MySql en MsSql (omdat je tegen de library werkt en niet meer direct tegen specifieke connecties/readers) en omdat er een aantal rariteiten van Oracle uit de code konden blijven. Daarnaast scheelde het een hoop werk omdat het (zeker destijds) een goede aanvulling was op de standaard database connectivity (diverse complimenten gehad van collega's).

Dus het is meer een uit de klauwen gelopen hobby dan een declarabel project
Voor nieuwe projecten ben ik aan het kijken of ik zaken als EF (of nu ik Dapper wel interessant vind mogelijk ook Dapper) kan inzetten. Maar voor de complexere applicaties ben ik op dit moment nog geen grote liefhebber van ORM. Het is historisch gegroeid in een aantal projecten dat we dicht op de DB werken middels mijn eigen wrapper. En wat mij betreft werkt dat nog steeds prima, en men zegt altijd: "Never change a winning team"