I have written a small application in ASP.NET Core to create and manage collections of cards for a collectable card game. I currently have a version that successfully downloads bulk card data via API call, parses the JSON response, and loads it into local SQL Server database. I then use the local data to add the cards to the collections, lookup prices, etc. As an academic exercise, I'm deliberately overcomplicating the design of this as if it were a large scale enterprise application since I really have no reason to build it other than to learn more about programming, so I'm wondering about best practices for something like this?
Currently I have the application broken into four projects: an API client for pulling the card data from the external API, a data access/domain layer using EF Core and SQL server, a service layer that orchestrates everything, and a Blazor Server UI. The main thing that I'm struggling with is that my service layer is dependent on both the API client and the DBContext, so I'm wondering if there's a good way to consolidate the dependencies, since the data from both sources are mapped to the same domain objects.
From what I've been reading, it seems like setting up a repository would be a good option and is common when there are multiple data sources being utilized. I have a 2nd version with repositories for accessing the local database but I'm not sure how to introduce the external API calls into this version. I think I could create separate implementations of the Card Repository Interface, one to access my local SQL database and another to access the external API but I'm not sure how the application would know when I need one or the other if I'm using dependency injection.
For example, periodically I want to check for updated card data from the external API and update my database with the new data, but for the most part I'll be reading the card data from the local database for managing the collections. Any advice on how to approach this? I can give code examples if needed. Thanks.