Architectural problems in repository pattern and unit of work

Question

I have implemented Repository pattern with Unit of work but have some architectural issues.

For example, lets say I am creating a used car parts online store. While I have operations on my DB I also have operations I need to perform on remote API's from different scrap yards e.g. need to run searches, availability updates and more...

I decided to try unit of work and repository pattern

Did things mostly like Mosh Hamedani but for asp.net core 2.1 From videos like this one

Unit of work and repositories work OK and make sense so long as I am using EF(or something else to communicate with DB) but it doesn't make much sense if I am to get some of the data trough different web apis. (e.g. getting list of cars on the market from different APIs whose handling and retrial is similar but different - I am retrieving different implementations of the same interface by key)

First I don't like the fact that I have all instances for all repositories inside my unit of work but need only one in most of the cases. I know it helps to reuse context transaction without wrapping it in my own but still its silly having unnecessary instances.

Second Should I implement retrieval logic and handling for remote api's also inside a repository and unit of work or maybe ditch unit of work and do something else? Keep just repositories? (Someone once mentioned facade pattern which I'm not familiar with)

I tend to overengineer things and right now I'm very confused. Any insight is helpful.

Answer 1

The repository pattern serves just one purpose: abstracting SQL from your application code. The unit of work pattern exists simply to support and coordinate transactional operations with multiple repositories. EF and other ORMs handle all this for you. Specifically with EF, each DbSet is a repository and the DbContext is the unit of work. When you use an ORM like EF, that is your data layer, rather than some custom class library you might have traditionally created. You should absolutely not be implementing the repository/unit of work patterns on top of something like EF.

What you're looking for essentially an API gateway. In microservice architecture, each service deals with one discrete unit of functionality, which means a cross-cutting application that uses many if not all of these microservices would have a ridiculous amount of dependencies. The most typical approach is creating one or more API gateways, which essentially package up communication with all or a particular subset of your microservices. Your application talks directly to the API gateway only, and the API gateway coordinates communication with all the microservices necessary to facilitate the application's request. This further allows you implement layers like a message queue in a seamless way.

Answer 2

Though I agree with answer from Chris Pratt, I think it is necessary to create repositories in some cases even though you are using ORM like EF. I have explained this in details here.

With your question, I suggest you should continue with UoW and Repository as you are doing so far. As mentioned here UoW is more than transaction. EF implements this perfectly for you if you properly use DbContext.

About problems involving APIs from other sources in current repository and UoW, it should be separate. I suggest you create separate wrapper for consuming complexity of third party APIs. Call this anything you want; repository or External Api Wrapper or whatever...