Yeah passing the open IDbConnection to keep the repository stateless is fine, but as it adds an extra param on every call in which case I’d probably just use extension methods and use the static class for grouping of related data access methods, e.g:
public static class SomethingRepoApi
{
public static Task DoSomethingAsync(this IDbConnection db, IAuthSession session) {}
}
Which reduces code coupling and improves discoverability as the shared namespace is imported and intelli-sense will show available APIs without needing explicitly to explicitly reference the Repository, e.g:
await Db.DoSomethingAsync(GetSession());
I’d probably only consider using a IContext for 3 or more properties, i.e. not 2 as there’s some overhead in creating a context and makes APIs less reusable in that you either need the context instance available or have all instances available to create the context whilst the API may not need to use them all.
I personally take a gradual approach where initially all my data access is kept in the Service, when I need to reuse data access implementations I’ll refactor it out into static extension methods, when it grows large enough that it needs more modular organization I’d use a “Repository” which inherits a custom RepositoryBase to reduce the boilerplate (but needs to be registered as a transient dependency so the open connection is disposed at the end of the request). So it’s essentially like option 1 but using a base class to reduce boilerplate. I’m not seeing the benefit from decoupling from IDbConnectionFactory as it’s defined in ServiceStack.Common which ServiceStack.OrmLite references so it’s not adding any additional dependencies/coupling.