Access modifiers and layer segregation.
Access modifiers (
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())
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
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).