I'm trying to build a repository layer for an application which interacts with 3 databases, all MSSQL. I made the repository structure is based on Dapper and Unit Of Work Pattern and looks like below:
Is this a good design? or what could be a better design for this?
I do not want to pass the connection instance from business, as it's not the job of a business layer; and should be of the data layer itself. Currently, am trying to manage the connection within the UnitOfWork class with the connection name and would like to change it.
EDIT: The design is not possible as it has multiple class inheritance, which is not possible in c#. Are there any alternate solutions?
There's very little info to work with here, but I'll try. It doesn't matter how many db you're using or their type. The repository with UoW is an anti pattern which becomes even worse with multiple dbs.
A repository should work with whole concepts (aggregates). I'm going the DDD route because is the easiest way to model things in an app. A repository will take care of one aggregate type. Its implementation will use dapper to work with the db.
If you need to modify multiple aggregates in one operation, first do make sure the business process is modeled properly (usually it's not). The business process itself is the UoW but this implies using Domain Events and a durable service bus (to be server crash resilient). And every message handler should be idempotent.
A repository should never know about other repos and the inheritance part is mostly a dubious design. The UoW inside the repo which enables the persistence of the whole aggregate regardless of how many objects it's made from, is the db transaction. Don't complicate your life with distributed transactions, keep a transaction per db.
That being said, it's obvious that a proper architecture (it has very little to do with the repository pattern, even less with dapper) needs someone with a lot of experience if you want a maintainable codebase. If you're a junior, ask a senior or take some time to learn DDD modelling properly. It's very easy to come up with 'solutions' that seem simple enough but are an unmaintainable mess.