Can I use Entity Framework with a SOAP API layer over a database?

Question

We have a hierarchical database at our institution that has exposed a SOAP endpoint as the only way to make CRUD operations against it. We are primarily a .NET Core shop. I'm trying to conceptualize how the architecture of an app that uses the WDSLs would look. The main use case is to display account info in a pleasing manner as well as being able to modify it with business logic behind the CRUD operations.

Is there a way to use Entity Framework Core with a SOAP API layer to access the database? If not, what is the recommended approach when architecting a solution that doesn't use Entity Framework Core for its connections? I'm trying to apply the Clean Architecture approach to this solution, but all examples I see use EF Core.

I've begun the task of storing the results of the main WSDL call, "getAccount", into a temporary SQL database on startup. Then I could query the SQL database as normal. I wasn't sure if this was standard practice or not.

The other approach would be to map all of the SOAP calls into a REST interface using Web API. Then I could just call the Web API and it would make the SOAP calls for me. I have started doing this manually, but I've seen tools that can "proxy" the SOAP layer. Would that be applicable?

Answer 1

EF is an ORM (Object-Relational Mapper). It's used to easily turn a relational database structure into .NET objects. Since you aren't connecting to a database (you have a SOAP API), I don't see what role EF would play here.

Your first solution describes forcing a role for EF by creating an unnecessary middle-man database where one wasn't before, just so EF can be used. I've never heard of that before, and I would cry a little inside if I had to work on a project with that kind of misdirection in place.

The most straightforward solution is just call the SOAP services directly (on the server side), which should be pretty easy to do. You're probably going to have all of the same WebAPI endpoints any way, it's just that the code behind them will be consuming a SOAP service instead of an EF context.