Skip to main content

In Entity Framework how do I wrap a database call with a call to another service and ensure they [Resolved]

I have an entity framework model called Employee. Whenever I request a list of all Employee rows I first want to make a soap request to get any new employees from another system and update the sql database with them.

Is there some sort of binding that I could apply to the model or would I just have to add another model that calls both and call it instead.

I'm wanting to make it so that I can't call the employee list from the database directly without refreshing it at each place in the razor pages where I call it.

Question Credit: Matt Ralston
Question Reference
Asked August 28, 2018
Posted Under: Programming
2 Answers

Access modifiers and layer segregation.

Access modifiers (public, private, internal, protected) make it possible for you to prevent an external caller from calling inner logic directly, and instead force them to use only the logic you have allowed them to access.

If you abstract your data access logic into a separate project/layer (known as the DAL), then you can achieve what you want.

As a simple example:

internal class MyContext : DbContext
    // ...

public class EmployeeRepository
    public List<Employee> GetEmployees()
        using(var db = new MyContext())

            return db.Employees.ToList();

    private void UpdateEmployeeList(MyContext db)
        var externalEmployeeList = GetExternalEmployeeList();

        foreach(var employee in externalEmployeeList)


An external caller can only get at the employee data by doing the following:

var employeeRepository = new EmployeeRepository();
var employees = employeeRepository.GetEmployees();

Therefore, it's impossible for them to bypass the additional SOAP call.

However, this does mean that external callers can't have direct access to MyContext and must always use methods that you've created for them.

In professional codebases, layer segregation is such a common occurrence that this is usually already the case anyway. I would expect any professional codebase to separate its DAL (data acccess layer) into a separate project and not leak its inner dependency (such as EF's DbContext).

While it's technically possible to do things like intercepting queries, this is not going to be easy to develop nor maintain.

What you're effectively asking for is the following:

I want to force external callers to use my logic (= enforcing the additional SOAP call) instead of just using EF directly.

The logical consequence is that you have to create your logic. This is the DAL I was talking about, it's a project that exists specifically to separate the external caller from EF, and instead force the external caller to use the DAL's logic (which will use EF if and when it wants to - the external caller doesn't get to make the decision).

credit: Flater
Answered August 28, 2018
Your Answer