[Question] Why it is not an extension to IConnection?
Closed this issue · 3 comments
Probably, that is a stupid question, but why not generate an extension class to IConnection instead of query class?
Developers might want to decide on their own how they create connections to db, it doesn't matter which db they use
"Developers might want to decide on their own how they create connections to db"
Why, though? I mean, connecting to a DB in C# is just a matter of providing the right connection string.
Can you provide a concrete example of when this will be beneficial, creating the connection somewhere else?
Regarding the technical suggestion, your suggestion is that the generated code will be something like this, right?
public static class QuerySql { public static async Task<GetAuthorRow?> GetAuthor(this IConnection me, GetAuthorArgs args) ... }
correct?
Regarding the technical suggestion, your suggestion is that the generated code will be something like this, right?
yes, extension class to IConnection object
Same as Dapper package provides Query<>() extension method
https://github.com/DapperLib/Dapper/blob/00a3808f7db14a2779e0ab9b4096b5405512a6f3/Dapper/SqlMapper.Async.cs#L14
Why, though? I mean, connecting to a DB in C# is just a matter of providing the right connection string.
In its basis, yes, we just pass connection string to db connection constructor, which works for hello-world project
But nowadays there are tons of projects that might have db connection factories that actually create and control lifecycle of dbconnection objects. With current implementation of the plugin, developers must reference generated QuerySql class to create a connection.
But in reality it is not really necessary, generated query logic is pretty straightforward and functional by its nature - it does query to dbconnection, then reads rows and converts them to data classes.
It doesn't really matter at some point which db provider is used. In case of some edgecases you always can cast connection reference to any type you need, user will specify type of db in the plugin settings anyway.
PS it might be an option to generate argument classes and data classes, and then generate code using Dapper package, it will reduce your efforts on writing and testing mapping-related code, Dapper does that job already
I am not sure about using Dapper or not (I'll open a different discussion - introducing an extra dependency is something I wish to avoid, if possible).
Regarding generating the code as extension to IConnection itself - I'll add it as an option, shouldn't be too hard.