Wow I love this with my full heart. Is this C# only or do you have plans for other languages (like Typescript? Please?)
I bet this idea blows up - ORMs are such a PITA, and I love tools like Dapper that just wrap the contrapositive of this behavior - this seems even better to me.
That's the comment I wanted! My thing is tightly integrated with Visual Studio, but the same approach would work for typescript. How many folks are talking to relational DBs with typescript? More and more I suppose?
Dapper has swept the world, but it still makes you maintain your own POCO, and your SQL is still in string literals, which has to be just the weirdest cultural practice. With my thing, because your SQL is in it's own file, we can constantly validate it, as you type, every time you save, every time you rebuild your queries, every time you run your tests.
Awesome! I've been using some slightly changed Poco Generator (I added nullable types, the generator was that old :D) from codeproject.com for this. But your project looks much better. I recently switched from VS to Rider, but this still looks great.
I like this, but am trying to figure out whether this is an option/possible:
1. Utilize an abstraction to connect to the database or what connection string is used. For example, using AAD vs shared credentials when connecting to the DB.
2. Centered around Stored Procedures. I'd like to have everyone focused on creating the SP and then having the model created automatically from that SP.
At design time, we use the connection string specified in the qfconfig.json file, or the one you specify in the .sql file. At run time, you supply the method that creates the connection, so you should be able to do whatever you want.
Stored procedures are automatically supported. It's just SQL. We can discover the return type and create the wrapper just as we can for a query. But SQL in it's own file feels so much like stored procedures, you might prefer to store and version your SQL with your app code rather than create procedures that live in the database.
6 comments
[ 3.3 ms ] story [ 19.3 ms ] threadI bet this idea blows up - ORMs are such a PITA, and I love tools like Dapper that just wrap the contrapositive of this behavior - this seems even better to me.
Dapper has swept the world, but it still makes you maintain your own POCO, and your SQL is still in string literals, which has to be just the weirdest cultural practice. With my thing, because your SQL is in it's own file, we can constantly validate it, as you type, every time you save, every time you rebuild your queries, every time you run your tests.
1. Utilize an abstraction to connect to the database or what connection string is used. For example, using AAD vs shared credentials when connecting to the DB.
2. Centered around Stored Procedures. I'd like to have everyone focused on creating the SP and then having the model created automatically from that SP.
Stored procedures are automatically supported. It's just SQL. We can discover the return type and create the wrapper just as we can for a query. But SQL in it's own file feels so much like stored procedures, you might prefer to store and version your SQL with your app code rather than create procedures that live in the database.