[C#/.NET] Dynamisch type creëren en opslaan met reflection

[Down]

In mijn programma lees ik input uit een database (SQL Server 2005) die elke keer anders kan zijn. Aan de hand van de columnnames die ik uit het resultaat lees maak ik met reflection een type aan met properties (waarbij de properties dus de namen van de columnnames hebben). Vervolgens maak ik een List van objecten van het zojuist gecreëerde type en vul ik deze met de daadwerkelijke waarden.

So far so good.

Vervolgens wil ik deze List met objecten serializen en opslaan in de database. Het komt er dus op neer dat ik een resultaat van een query wil opslaan in de database. Hierbij heb ik twee opties geprobeerd, namelijk serializen als binary met een BinaryFormatter en serializen als XML.

Voor serializen als XML stuitte ik al snel op een probleem, het lukte me namelijk niet om de properties van het customtype het attribuut [XmlInclude] mee te geven. Heb me helemaal suf gegoogled maar ben er niet uitgekomen. Met de PropertyBuilder is het me niet gelukt.

Vervolgens geprobeerd te serializen als binary en op te slaan, hetgeen prima werkt (door het hele type als serializable te markeren). Bij het uitlezen kan ik het resultaat echter niet casten naar het juiste type, omdat ik dit type de voorgaande keer dynamisch heb gemaakt. Dit type had ik gecreëerd op een assembly die ik speciaal had gemaakt voor het 'holden' van deze type. Dit type verandert echter elke keer. Hoe ga ik voor elk resultaat dat ik opsla bijhouden van welke type deze resultaten zijn?

Of kan ik beter het resultaat serializeren als XML?

Het lijkt me vrij recht toe recht aan om aan de hand van de XML het type met reflection te recreëren, maar dan moet ik wel de properties van het type een attribuut mee kunnen geven.

Anyone?

[RobIII]

Just out of curiosity: wat ben je nou precies aan 't doen? En waarom? Je haalt "dynamische" zaken uit de DB op en slaat diezelfde zaken weer op in de DB Ik kan er even geen touw aan vast knopen waarom je dat zou willen hoewel je verhaal me verder wel duidelijk lijkt...

[Down]

RobIII schreef op dinsdag 21 april 2009 @ 19:15:
Just out of curiosity: wat ben je nou precies aan 't doen? En waarom? Je haalt "dynamische" zaken uit de DB op en slaat diezelfde zaken weer op in de DB Ik kan er even geen touw aan vast knopen waarom je dat zou willen hoewel je verhaal me verder wel duidelijk lijkt...

Het functionele aspect heb ik niet zelf verzonnen .

Het komt er op neer dat vanuit mijn programma SqlCommands door de gebruiker kunnen worden uitgevoerd (text of stored procedures). Deze commands en hun resultaat moeten worden opgeslagen zodat deze later kunnen worden bezichtigd. Dit geldt dus ook voor Commands met het type Reader waarbij de Command een grote hoeveelheid data kan teruggeven.

Iemand wil dit kunnen

Pseudocode:

code:

string command = 'exec sp_dummy';
ExecuteSqlCommand(command);
result = ReadResultFromCommand();
CustomType = CreateCustomTypeFromResult(result); 
List<CustomType> resultList = CreateList(result);
InsertIntoDatabase(command, resultList);

Vervolgens..

code:

result = ReadResultFromDatabase() as CustomType; // probleem..

[Janoz]

Imodium schreef op dinsdag 21 april 2009 @ 19:29:
Het functionele aspect heb ik niet zelf verzonnen .

Het functionele aspect misschien niet, maar de technische oplossing wel. Reflection en runtime gegenereerde code vallen allemaal onder het kopje 'eval is evil'. Je moet wel een behoorlijk grote verdediging opzetten wanneer je ze wilt gebruiken.

Ook in wat ik tot nu toe in dit topic gelezen heb zie ik nog geen reden voor reflection. Het enige wat je nodig hebt is immers gewoon een Map (of Dictionary, ben niet zo thuis in de .net classes) waarbij de key de kolom naam is en de value de daadwerkelijke value. Ik zie geen enkele reden om daarvoor dynamische typen voor te gaan misbruiken eigenlijk.

[ Voor 4% gewijzigd door Janoz op 21-04-2009 19:57 ]

[Down]

Janoz schreef op dinsdag 21 april 2009 @ 19:57:
[...]


Het functionele aspect misschien niet, maar de technische oplossing wel. Reflection en runtime gegenereerde code vallen allemaal onder het kopje 'eval is evil'. Je moet wel een behoorlijk grote verdediging opzetten wanneer je ze wilt gebruiken.

Ook in wat ik tot nu toe in dit topic gelezen heb zie ik nog geen reden voor reflection. Het enige wat je nodig hebt is immers gewoon een Map (of Dictionary, ben niet zo thuis in de .net classes) waarbij de key de kolom naam is en de value de daadwerkelijke value. Ik zie geen enkele reden om daarvoor dynamische typen voor te gaan misbruiken eigenlijk.

Het programma is juist bedoeld voor een database admin die sowieso toegang heeft tot alle systemen, beveiliging is in dit geval geenszins van toepassing.

Dat argument terzijde, waarom is dit het misbruiken van dynamische types? Ik vind het juist vanuit een OO standpunt mooi dat alle velden als data worden opgeslagen als properties van een resultaat object.

[Janoz]

"eval is evil" gaat misschien vaak wel over security, maar security is maar een klein onderdeel. Dynamische code is foutgevoelliger, erg inefficient en enorm lastig te onderhouden en debuggen.

Het OO standpunt ben ik niet met je eens. Je objecten definieer je design time. Encapsulation en seperation of responcibility zijn dingen die het de ontwikkelaar makkelijk maken. Voor de Computer waarop het draait maakt het geen kont uit.

Zou je vanuit OO standpunt naar je probleem kijken dan zou je imho juist eerder bij een maplike oplossing uitkomen. Ja, er zal zeker een bak properties in het object terecht komen, maar die zijn dynamisch, maak die dan ook dynamisch in je code. Zoekende naar een object met een verzameling key value pairs kun je eigenlijk gewoon niet ergens anders uitkomen dan bij een map / dictionary.

Probeer je eens voor te de geest te halen hoe de computer bij het deserializeren ineens de vorm van het object moet gaan verzinnen. Het is immers ooit eens dynamisch gegenereerd op basis van wat gegevens die, op een veel later moment bij het uitlezen van de betreffende data, al lang niet meer beschikbaar zijn.

[BCC]

Kun je tegenwoordig eigenlijk ook al duck-typen in C#?

[Snake]

BCC schreef op dinsdag 21 april 2009 @ 20:21:
Kun je tegenwoordig eigenlijk ook al duck-typen in C#?

Dat zou moeten gaan in .NET 4.0

[Down]

Janoz schreef op dinsdag 21 april 2009 @ 20:19:
"eval is evil" gaat misschien vaak wel over security, maar security is maar een klein onderdeel. Dynamische code is foutgevoelliger, erg inefficient en enorm lastig te onderhouden en debuggen.

Het OO standpunt ben ik niet met je eens. Je objecten definieer je design time. Encapsulation en seperation of responcibility zijn dingen die het de ontwikkelaar makkelijk maken. Voor de Computer waarop het draait maakt het geen kont uit.

Zou je vanuit OO standpunt naar je probleem kijken dan zou je imho juist eerder bij een maplike oplossing uitkomen. Ja, er zal zeker een bak properties in het object terecht komen, maar die zijn dynamisch, maak die dan ook dynamisch in je code. Zoekende naar een object met een verzameling key value pairs kun je eigenlijk gewoon niet ergens anders uitkomen dan bij een map / dictionary.

Probeer je eens voor te de geest te halen hoe de computer bij het deserializeren ineens de vorm van het object moet gaan verzinnen. Het is immers ooit eens dynamisch gegenereerd op basis van wat gegevens die, op een veel later moment bij het uitlezen van de betreffende data, al lang niet meer beschikbaar zijn.

Is encapsuleren juist niet wat ik doe? Waarom zou het feit dat het dynamisch gebeurt daar iets aan af doen?

Dat het lastiger te debuggen en onderhouden is, is wellicht waar. De betreffende code is echter dusdanig klein dat dit geloof ik wel te overzien is.

In jouw voorbeeld moet ik voor elke column een Dictionary aanmaken. Dit zal uiteraard wel werken maar hierbij trek je de data ook uit elkaar en mooi vind ik het persoonlijk niet.

Over deserializen, in mijn openingspost geef ik al aan "Hoe ga ik voor elk resultaat dat ik opsla bijhouden van welke type deze resultaten zijn?" dus daar heb ik zeker wel over nagedacht. Daarom haalde ik ook nogmaals de XML Serializer aan.

Ik hou me nog steeds aanbevolen als iemand weet hoe ik attributen aan properties kan toevoegen met reflection.

[pedorus]

Even kijken hoor. Er wordt dus data uit een database gelezen, deze wordt in een dynamisch type gestopt, en vervolgens alleen maar geserialiseerd in een database gestopt? Waarom doet mij dit sterk denken aan The daily WTF?

[Down]

pedorus schreef op dinsdag 21 april 2009 @ 20:36:
Even kijken hoor. Er wordt dus data uit een database gelezen, deze wordt in een dynamisch type gestopt, en vervolgens alleen maar geserialiseerd in een database gestopt? Waarom doet mij dit sterk denken aan The daily WTF?

Omdat je mijn posts niet hebt gelezen? Nogmaals: vanuit functioneel oogpunt is het belangrijk dat er achteraf kan worden nagegaan welk resultaat een bepaald commando op een bepaald tijdstip gaf. Deze data zal ik dus op één of andere manier moeten opslaan. (weliswaar in een andere database)

[ Voor 24% gewijzigd door Down op 21-04-2009 20:44 ]

[FerroFiber]

SELECT INTO misschien een oplossing?

[pedorus]

Imodium schreef op dinsdag 21 april 2009 @ 20:38:
[...]


Omdat je mijn posts niet hebt gelezen? Nogmaals: vanuit functioneel oogpunt is het belangrijk dat er achteraf kan worden nagegaan welk resultaat een bepaald commando op een bepaald tijdstip gaf. Deze data zal ik dus op één of andere manier moeten opslaan. (weliswaar in een andere database)

Nou ja, het lijkt me dan dat een simpel select into commando volstaat om het resultaat van een query op te slaan in een andere database. Eventueel nog een klein schilletje eromheen om de metadata goed op te slaan, maar dat is dan ook alles

edit:
bah, net te laat

[.oisyn]

Imodium schreef op dinsdag 21 april 2009 @ 20:31:
In jouw voorbeeld moet ik voor elke column een Dictionary aanmaken.

Nou, nee, dat is juist vrij zinloos. De kolomnamen zijn de dingen die je wilt indexeren, dus een Dictionary per kolom brengt je nergens. Feitelijk wil je een Dictionary per rij als je de data bij elkaar wilt houden, of een enkele Dictionary als je kunt leven met een resultaten-array per kolom. Waar het iig op neer komt is dat je min of meer dit kunt doen:

C#:

personen = GetDataFromDB();
for (int i = 0; i < personen.Length; i++)
{
    string naam = personen[i]["naam"];
    string adres = personen[i]["adres"];
    // etc.
}

Je dynamische type is leuk gevonden, maar hoe ga je dat in hemelsnaam fatsoenlijk benaderen vanuit statische code?

[ Voor 7% gewijzigd door .oisyn op 21-04-2009 21:15 ]

[Janoz]

Imodium schreef op dinsdag 21 april 2009 @ 20:31:
Is encapsuleren juist niet wat ik doe? Waarom zou het feit dat het dynamisch gebeurt daar iets aan af doen?

Nee.

Encapsuling is iets om het voor de ontwerper/ontwikkelaar makkelijk te houden. Voor de computer maakt het geen kont uit dat een applicatie volledige spagetticode is. Veel OO aspecten zijn juist bedacht om een uitgebreid probleem op te kunnen hakken in voor de mens te bevatten kleine brokjes. Het heeft dus werkelijk geen enkele toegevoegde waarde wanneer je dit enkel in de realm van de computer zelf uit gaat voeren. Daarop zijn die principes helemaal niet van toepassing.

Dat het lastiger te debuggen en onderhouden is, is wellicht waar. De betreffende code is echter dusdanig klein dat dit geloof ik wel te overzien is.

De code die de reflectie doet is misschien klein, maar de crux zit hem vooral in de dynamische code die uitgevoerd wordt. Die code bestaat namelijk alleen maar tijdens de uitvoer van je applicatie (waarin gelijk ook het andere probleem schuilt. Die code bestaat immers enkel op het moment van het uitlezen van de resultset. Bij het deserialiseren van je data is die code al lang weer weg, maar dat heb ik eerder ook al aangegeven)

In jouw voorbeeld moet ik voor elke column een Dictionary aanmaken. Dit zal uiteraard wel werken maar hierbij trek je de data ook uit elkaar en mooi vind ik het persoonlijk niet.

Nee, je leest het niet goed. Niet voor elke column, maar voor elke row. In principe doe ik dan helemaal niks anders dan dat jij doet. ook ik heb een object met dynamische properties (de entries in de dictionary), alleen lukt het in mijn oplossing met de basis componenten van .NET en zonder ook maar een vleugje dynamische code.

Over deserializen, in mijn openingspost geef ik al aan "Hoe ga ik voor elk resultaat dat ik opsla bijhouden van welke type deze resultaten zijn?" dus daar heb ik zeker wel over nagedacht. Daarom haalde ik ook nogmaals de XML Serializer aan.

Waarmee je uiteindelijk je probleem op de verkeerde plek aan het oplossen bent. Wat weerhoud je ervan om in je dictoinary niet een string als key, maar een metadata object te gebruiken? Of waarom gebruik je niet gewoon een metadata object waarin de value ook opgeslagen kan worden. Dan kan een enkel record gerepresenteerd worden door een lijst van die metadata objecten.

Ik hou me nog steeds aanbevolen als iemand weet hoe ik attributen aan properties kan toevoegen met reflection.

Vreemde zin. Je hebt een probleem, maar in de probleemstelling beperk je jezelf tot een specifieke oplossingsrichting. Is je werkelijke probleem niet gewoon:
"Ik hou me nog steeds aanbevolen als iemand weet hoe ik attributen aan properties kan toevoegen."

[Down]

Janoz schreef op dinsdag 21 april 2009 @ 21:19:


Nee.

Encapsuling is iets om het voor de ontwerper/ontwikkelaar makkelijk te houden. Voor de computer maakt het geen kont uit dat een applicatie volledige spagetticode is. Veel OO aspecten zijn juist bedacht om een uitgebreid probleem op te kunnen hakken in voor de mens te bevatten kleine brokjes. Het heeft dus werkelijk geen enkele toegevoegde waarde wanneer je dit enkel in de realm van de computer zelf uit gaat voeren. Daarop zijn die principes helemaal niet van toepassing.

I concede, je hebt gelijk

De code die de reflectie doet is misschien klein, maar de crux zit hem vooral in de dynamische code die uitgevoerd wordt. Die code bestaat namelijk alleen maar tijdens de uitvoer van je applicatie (waarin gelijk ook het andere probleem schuilt. Die code bestaat immers enkel op het moment van het uitlezen van de resultset. Bij het deserialiseren van je data is die code al lang weer weg, maar dat heb ik eerder ook al aangegeven)

Dat besef ik me heel goed. Daarom vraag ik me af of het misschien handig is om het customtype op de één of andere manier op te slaan. Door bijvoorbeeld de hele zaak te serializen als XML en zo later weer het type herstellen aan de hand van de XML. Dat dat enigszins omslachtig is geef ik wel toe.

Nee, je leest het niet goed. Niet voor elke column, maar voor elke row. In principe doe ik dan helemaal niks anders dan dat jij doet. ook ik heb een object met dynamische properties (de entries in de dictionary), alleen lukt het in mijn oplossing met de basis componenten van .NET en zonder ook maar een vleugje dynamische code.

Waarmee je uiteindelijk je probleem op de verkeerde plek aan het oplossen bent. Wat weerhoud je ervan om in je dictoinary niet een string als key, maar een metadata object te gebruiken? Of waarom gebruik je niet gewoon een metadata object waarin de value ook opgeslagen kan worden. Dan kan een enkel record gerepresenteerd worden door een lijst van die metadata objecten.

Dit klinkt inderdaad als een simpele aanpak. Ik ga er even over nadenken

Vreemde zin. Je hebt een probleem, maar in de probleemstelling beperk je jezelf tot een specifieke oplossingsrichting. Is je werkelijke probleem niet gewoon:
"Ik hou me nog steeds aanbevolen als iemand weet hoe ik attributen aan properties kan toevoegen."

Die indruk wil ik zeker niet wekken. Ik sta wel degelijk open voor andere oplossingsrichtingen. Ik zou gewoon graag willen weten hoe een attribute aan een property toe te voegen met reflection, los van dit gehele vraagstuk.


.oisyn: Door het dynamische type te serializen als XML zou ik het type een volgende keer weer kunnen herstellen adhv hoe deze is gedefineerd in de XML? (rootnode als type en de andere nodes als properties)

[.oisyn]

Imodium schreef op dinsdag 21 april 2009 @ 21:59:
.oisyn: Door het dynamische type te serializen als XML zou ik het type een volgende keer weer kunnen herstellen adhv hoe deze is gedefineerd in de XML? (rootnode als type en de andere nodes als properties)

Weer te herstellen als dynamische types bedoel je? Prima, maar hoe benader je de data daadwerkelijk? Of is het enige wat je ermee doet gewoon weer terug in de database stoppen?

[pedorus]

Imodium schreef op dinsdag 21 april 2009 @ 21:59:
Die indruk wil ik zeker niet wekken. Ik sta wel degelijk open voor andere oplossingsrichtingen. Ik zou gewoon graag willen weten hoe een attribute aan een property toe te voegen met reflection, los van dit gehele vraagstuk.

^{Met SetCustomAttribute (voorbeeldje).}

Voor dit probleem is die methode echt een enorme omweg en een ernstige WTF. Je bent gewaarschuwd. Ik snap eigenlijk niet waarom je data die in weze een tabel vormt niet gewoon als een tabel in een database zou opslaan. Een tabel zal waarschijnlijk vele malen efficienter (snelheid+grootte) en gemakkelijker zijn, daar is zo'n database namelijk op gemaakt... Ook zul je zien dat zo'n tabel alle types ook nog eens goed afhandelt...

[Down]

pedorus schreef op dinsdag 21 april 2009 @ 22:52:
[...]

^{Met SetCustomAttribute (voorbeeldje).}

Voor dit probleem is die methode echt een enorme omweg en een ernstige WTF. Je bent gewaarschuwd. Ik snap eigenlijk niet waarom je data die in weze een tabel vormt niet gewoon als een tabel in een database zou opslaan. Een tabel zal waarschijnlijk vele malen efficienter (snelheid+grootte) en gemakkelijker zijn, daar is zo'n database namelijk op gemaakt... Ook zul je zien dat zo'n tabel alle types ook nog eens goed afhandelt...

SetCustomAttribute attribute had ik gevonden, maar deze is specifiek bedoeld voor het maken van custom attributes via een CustomAttributeBuilder, ik wilde graag een bestaand attribute toevoegen, dat lijkt niet te werken.

Inmiddels heb ik de reflection omgeruild voor een manier waarbij ik een record opsla als List van MetaDataHolders (met daarin naam/type/value).

De manier die jij voorstelt gaat niet lukken. Een SqlCommand kan worden uitgevoerd op een database (die op een bepaalde server draait) waarbij dit resultaat is gekoppeld aan zowel de command als de server. Er kunnen meerdere commands achter elkaar worden uitgevoerd (op meerdere databases van hetzelfde type maar op verschillende servers, met wellicht dezelfde resultaten). Hoe zie jij voor je om overzichtelijk voor elk resultaat een tabel te maken en deze een volgende keer ook weer uit te lezen?

Ik denk dat het probleem sowieso is ontstaan omdat in de eerste carnatie het opslaan van het resultaat niet nodig was en ik even kon spelen met reflection. Enfin. Case closed wat mij betreft

@.oisyn: wat ik bedoelde is ongeveer dit:

C#:

List<MyType> results = GetResults();
SaveResults(results.SerializeAsXml());

//

object results = ReadResults();
Type MyType = CreateTypeFromXml();
List<MyType> = results as List<MyType>;

Ik denk echter dat dit slechts een type is die er hetzelfde uit ziet, maar niet werkelijk hetzelfde is. Hm..

[.oisyn]

Dat werkt dus niet. Je kunt niet zomaar een variabele (wat MyType is) opgeven als argument voor een generic type. En dat is meteen de hele kern van de issue: je kunt wel dynamisch types gaan maken, maar er is totaal geen manier om die dynamische types vervolgens te gebruiken in je verder statische programma, tenzij je voor de access van die dynamische types ook weer reflection gaat gebruiken. Een enorme omweg dus, die totaal niet handig is in het gebruik.

C#:

// dit is wat jij wil, maar dat kan niet
Type MyType = GetTypeFromXml(xml);
MyType obj = GetObjectFromXml(xml);
string foo = obj.property1;
obj.property2 = bar;

/*******************************************************/

// dit kan wel, maar is waarschijnlijk niet wat jij wilt
Type MyType = GetTypeFromXml(xml);
object obj = GetObjectFromXml(xml);

PropertyInfo property1 = MyType.GetProperty("property1");
string foo = (string)property1.GetValue(obj, null);

PropertyInfo property2 = MyType.GetProperty("property2");
property2.SetValue(obj, bar, null);

[ Voor 43% gewijzigd door .oisyn op 22-04-2009 01:16 ]

[pedorus]

Imodium schreef op dinsdag 21 april 2009 @ 23:22:
SetCustomAttribute attribute had ik gevonden, maar deze is specifiek bedoeld voor het maken van custom attributes via een CustomAttributeBuilder, ik wilde graag een bestaand attribute toevoegen, dat lijkt niet te werken.

Het voorbeeld met DescriptionAttribute is met een bestaand attribuut.

Inmiddels heb ik de reflection omgeruild voor een manier waarbij ik een record opsla als List van MetaDataHolders (met daarin naam/type/value).

MetaDataHolder is denk ik een eigen class, dus ik weet niet zeker of het gebeurd, maar het lijkt me niet zo efficiënt om naam en type voor iedere record opnieuw op te slaan.

De manier die jij voorstelt gaat niet lukken. Een SqlCommand kan worden uitgevoerd op een database (die op een bepaalde server draait) waarbij dit resultaat is gekoppeld aan zowel de command als de server. Er kunnen meerdere commands achter elkaar worden uitgevoerd (op meerdere databases van hetzelfde type maar op verschillende servers, met wellicht dezelfde resultaten). Hoe zie jij voor je om overzichtelijk voor elk resultaat een tabel te maken en deze een volgende keer ook weer uit te lezen?

Je slaat ze gewoon op in allemaal losse tabellen die je automatisch aanmaakt? Het maken van een tabel en het weergeven daarvan is natuurlijk erg simpel, net als een lijstje met gedraaide commando's. Je krijgt hooguit wat veel tabellen, maar het opzoeken en maken van een tabel is toch ongeveer O(1) voor de hoeveelheid tabellen.

[Woy]

Ik ben het met de rest eens dat een Custom-Type me voor dit probleem niet de beste oplossing lijkt.

Een dictionary kun je toch ook perfect naar XML serializeren en later weer deserializeren?

Je bent nu een custom type aan het bouwen waar je voor de rest niet zoveel mee doet behalve weer serializeren. Aangezien je compile time de properties nog niet weet kun je er in je code dus ook niet zoveel mee.

Een simpele class met een dictionary, en een stukje code om dat netjes te (de)serializeren in het formaat dat jij dat wilt lijkt mij toch echt het makkelijst, en best onderhoudbaar.

[jos707]

Je voorgestelde oplossing om het resultaat op te slaan in een andere databank met voor elk veld het juiste type lijkt me wel mogelijk met SqlBulkCopy.