micro-orm | micro framework for create a very simple decoupled ORM | Database library

Personally, there is a lot of danger in keeping a connection open and reusing it, especially across multiple user contexts. The chance of inserting wrong is very high.

As for your statement "without re-opening a connection", what is the purpose of not "reopening". I ask this as SQL connections are not actually disposed of when you dispose them. The connection is cleared out and goes into a pool underneath the hood. What this means is you are not incurring any overhead "re-instantiating" the object from the pool. Your code has the safety of disposal, but there is no overhead. NOTE I am assuming the idea of having object creation overhead is the perceived issue.

This is why Microsoft has you shut them down every time, but has made the pool underneath the hood. Yes, the pool objects can time out, but you are throwing things at it quickly enough it will not reach the time out (default == 30 seconds).

NOTE: Even Dapper does not do anything special to really destroy the connection object (i.e. they did not circumvent .NET and reinvent the wheel).

Following the above, the best practice is to allow the objects to Dispose and go back into pool. I know it seems a bit counterintuitive, but once you realize there is an internal pool object, it makes sense.

If you want a thought experiment about running multiple commands in a row, you can consider creating the commands as units of work and rapidly feeding them. You would need a bit of command management in your repo, but it is sounder than creating a single connection and waiting until you are finished with the object to Dispose (as a failure to Dispose, in some instances, could be BAAAAADDDD).

So after some direction from @Chetan Ranpariya, Eventually figured it out.