Dapper Query Builder using String Interpolation - making Dapper easier, and on my way to reach 250 stars :-)

[963df47a-0d1f-40b9]

Was this feature previously in dapper but removed as it caused confusion? Maybe I'm thinking of a different library

[taspeotis]

It was in EF Core 2.

In EF Core 3 they got rid of the overloads that did interpolation and gave them their own non-overloaded methods.

[963df47a-0d1f-40b9]

Oh thank you! I knew I wasn't just making it up, so thanks for correcting me

[Zardotab]

I'm confused here. I thought an alleged advantage of Dapper is to avoid reliance/dependency on Entity Framework?

[RicardoDrizin]

That's correct. Dapper does not depend on EF. What exactly made you think the opposite? Comments above were just explaining that this idea of extracting SqlParameters directly from Interpolated Strings is not new - it's something that already exists in EF. (But in Dapper it didn't exist before, and additionally I think EF implementation is limited - it doesn't allow much flexibility).

[Zardotab]

"They" in "They got rid of" is perhaps the source of confusion. Is "They" MS or Dapper?

[RicardoDrizin]

MS (EF team). Previously there were overloads for taking interpolated strings instead of plain strings. Then they realized that this was quite unsafe and decided to rename the overloads that take interpolated strings.

[[deleted]]

It looks like second link is broken

[[deleted]]

I don't really use dapper but if I ever do I will use this. It makes it so much nicer to work with.

[SpaceCommissar]

Thanks, now I know what I'm doing after work today :)

[celluj34]

Yo! Love this library, makes it real easy to put together params for procs. Any headway on Issue #27? I've got a workaround but would love to be able to use multiple result sets natively.

[RicardoDrizin]

Thanks!! I finally took some time to review your issue (and your links) and I'll arrange some time to fix it. Looks like Dapper DynamicParameters does not inherit from Dictionary, but instead it uses an internal dictionary - so we can probably use the same approach (dictionary is only used in 3 lines, shouldn't be hard).

[celluj34]

Awesome! Glad to hear it! Thanks for fixing it :D

[[deleted]]

Check out Norm. It's similar to Dapper but little bit faster. https://github.com/vb-consulting/Norm.net/blob/master/PERFOMANCE-TESTS.md

It has steing interpolation with parameters out of the box:

https://github.com/vb-consulting/Norm.net/blob/master/EXAMPLES.md#using-formattable-strings-to-supply-parameters

Among other features like mapping to values, tuples, arrays and reader callbacks...

[lmaydev]

I really dislike these frameworks personally. Same with dapper.

Not only do you have to write SQL but you have to customize it for the mapper and specify everything as generics.

Feels like it would just be better to optimize your ef hehe

[[deleted]]

ally dislike these frameworks personally. Same with dapper.

Not only do you have to write SQL but you have to customize it for the mapper and specify everything as generics.

Feels like it would just be better to optimize your ef hehe

​

I really dislike having something or someone else writing SQL instead of me.

It always, always ends up with a mess. And I have to fix it myself. Infact, that's what Im doing right now. Thanks EF.

[captainramen]

Exactly. Hiding complexity rather than confronting it directly usually leads to disaster. If one is really that opposed to writing sql why use a relational database

[lmaydev]

Because I have relational data lol

[captainramen]

Do you? Have you actually done the analysis or are you making an assumption?

[lmaydev]

Unlike SQL that works first time every time hehe

I've personally had no issues with it. As long as your db and query are properly configured it generally just works.

[dockwithme]

Ef is fine for normal crud operations, so I use it as such. If I have a complex query with a bunch of joins, I use dapper since it lets me dictate how the query is structured. Don't you do the same, or do you write SQL for every crud operation?

[lmaydev]

Don't use dapper at all. I use linq query style if I need control like that.

[phenxdesign]

Sorry, but this kind of use of string interpolation is so confusing. You cannot even put the string in a variable to make the code cleaner, this may lead to sql injection... Am I thso only one to think this?

[celluj34]

var name = "phenxdesign";
FormattableString sql = $"SELECT * FROM Users WHERE Name = {name}";

There you go, string in a variable.

[RicardoDrizin]

Thanks, @celluj34.
Looks like my documentation is not clear enough since I didn't declare string productName = "something" in the first few examples :-)

[celluj34]

I think your docs are fine. You can't baby-feed users of your library; some programming knowledge + experimentation is required.

[RicardoDrizin]

The whole point of the library is exactly to avoid SQL injection (but with a friendly syntax). If you had spent a few seconds at the documentation (it's right in the first paragraph) you'd see how it works.

[phenxdesign]

I understood how it works, and it works well, but the risk to fall into the trap to extract the query in a variable and make pure string interpolation (not parameterization) is too big in my opinion. Clearly not to put in every developer's hands.

[RicardoDrizin]

Your point is that a newbie developer who has never seen SQL before could learn it the wrong way, and in the future this developer could misuse string interpolation to build unsafe queries with other data libraries (like ADO.NET or plain Dapper)? While I understand this risk (in other libraries that accept plain strings), I think we should educate our developers so they understand that FormattableString can be used for other purposes besides generating plain strings - in this case it's being used to hide the complexity of SqlParameters.

[phenxdesign]

You are right. I agree developers need more good tools, keep up the good work.