[C#] Dynamisch properties toevoegen aan anonymous object

[Avalaxy]

Ik probeer met Dapper ORM een query uit te voeren. Om dit te kunnen doen zijn een aantal parameters nodig, omdat het een soort prepared statement is. Deze parameters geef je mee door in de tweede parameter van de Query<T> methode een anonymous object te stoppen met daarin de naam + value van je parameter.

Echter probeer ik dynamisch een query op te bouwen. Zodra een bepaalde parameter gebruikt moet worden stop in de naam + waarde van deze parameter in een dictionary en verwerk ik in de SQL query een plek waar die parameter gebruikt moet worden.

Het grote probleem echter: ik heb dan een dictionary met een aantal parameters (meestal ~3), die ik dus in een anonymous object moet stoppen. Ik wil echter niet wélke parameters ik heb omdat dit dynamisch wordt opgebouwd. Er is keuze uit 5 parameters, en die kunnen allemaal willekeurig wel/niet aanwezig zijn en dus wel/niet in de query verwerkt worden.

Soms zou ik dus zoiets moeten krijgen:

C#:

var anon = new { a = A, b = B };

En soms zoiets:

C#:

var anon = new { b = B, c = C, e = E };

Ik heb al heel erg veel lopen zoeken naar hoe ik de key/values uit een dictionary in een anonymous object stop, ik heb een dynamic dictionary geprobeerd, ik heb het e.e.a. met LINQ geprobeer, maar ik kom er maar niet uit hoe ik nou dynamisch parameters mee kan geven aan m'n query.

[[ti]]

In de testcases van Dapper staat een voorbeeld van een IDynamicParameters query. Kun je dat niet aanpassen aan jouw scenario?

[ Voor 38% gewijzigd door [ti] op 04-10-2011 14:23 ]

[Niemand_Anders]

Ik zelf maak eigenlijk meer gebruik van query by example.

C#:

User queryUsr = new User { Country='NL' };
List<User> users = conn.ExecuteMapperQuery("SELECT Username, Email FROM Users WHERE (Country=@Country)", queryUsr, trans);

In bovenstaand geval pakt Dapper automatisch het Country veld. Dapper heeft niet echt support voor super dynamische queries waarbij velden en parameters wisselen. Dapper is meer een shortcut voor het gebruik van de SqlDataReader en het terug geven van de resultaten via een Read() loop.

Dapper zelf maakt gebruik van een dynamsch object omdat het niet weet welke records er terug komen uit de database. Via reflection kijkt dapper welke properties JOUW object heeft en probeert deze te benaderen op het dynamische object.

Wat je nog wel zou kunnen proberen is in plaats van een dictionary op te bouwen je zelf een dynamisch object aanmaakt en deze properties en values toe kent en dit dynamisch object vervolgens doorgeeft aan Dapper.

[Grijze Vos]

Kun je ipv een dictionary niet gewoon een dynamic gebruiken? Lijkt me precies wat je wilt hebben hier.

[Avalaxy]

Mja, maakt niet veel uit, een dynamic kan ik niet gebruiken omdat ik dan een error krijg dat dat niet kan met extension methods. Er moet dus echt een anonymous object in. Het verschil zover ik weet is dat bij een anonymous object compile-time een object wordt gegenereerd en dat een dynamic pas run-time bekeken wordt. Anyhow pakt Dapper dat niet zonder enorm omwegen.

Ik denk dat ik het dus maar gewoon oplos door de parameters compleet weg te laten en deze waardes in de query te verwerken (met de nodige escaping). Bespaart een hoop andere ranzige work-arounds om een probleem op te lossen waar Dapper (kennelijk) niet voor gemaakt is.

[D-Raven]

Je zou lijntje op kunnen gooien bij @samsaffron of op stackoverflow een vraag kunnen posten. Vragen m.b.t Dapper wordt behoorlijk snel op gereageerd. Wellicht hebben zij een oplossing voor je probleem?

[__fred__]

Ik zou ook eens naar IDynamicParameters kijken, maar als je het echt wilt, dan kun je wellicht wat met Reflection.Emit stoeien:

http://www.developmentalmadness.com/archive/2008/02/12/extend-anonymous-types-using.aspx

Er is w.m.b.t. nooit een excuus om geen parametrized queries te gebruiken.

[ Voor 10% gewijzigd door __fred__ op 04-10-2011 22:10 ]

[Avalaxy]

Ik moet heel eerlijk bekennen dat ik er aan de hand van het voorbeeld niet echt uit kom wat die IDynamicParameters nou doet/hoe het werkt

Heb het in ieder geval werkend allemaal zonder parameters, dus dat is positief Was meer een pragmatische keuze. Mocht het toepassen van IDynamicParameters niet te moeilijk zijn kan ik het wel weer verbouwen.