It sounds like you are trying to model a set of disparate data sources as a single model.
If that is indeed the case, my opinion is that creating a project to make the abstraction is the way to go.
I say that because you are dealing with different TYPES of sources. For example, if you just had two databases you could put a link between them, and abstract that way.
But, you have a data warehouse, a few web services, and Active Directory to deal with. I don't know if there would be one way to consolidate across all of those, and even if there were, it could be messy.
Putting the abstraction in a separate project also ensures that you only have to change ONE place when your entities change. It also ensures that you hide the details of what is going on behind the scenes from your front end. This can be important, particularly when you have to add something else (not if - with that many sources something else will surely come along later).
When naming classes it's often tempting to include words that describe usage in programming terms. These words might include abstract, entity, and/or base. So you end up creating classes like AbstractOffice or BaseOffice. The name of the class implies two meanings what it does Office and how it's used Abstract. I don't recommend doing this. It adds extra details in the name that it doesn't need.
KISS (Keep It Simple Stupid)
I recently refactored a project I did a year ago to use simple names, and it became much easier to read the code. Give it a try and see if it helps. You can always rename the classes later.
public class Employee : Data
{
public int Id { get; set; }
public string LastName { get; set; }
public string FirstName { get; set; }
}
[Sql(@"SELECT [EmployeeId], [LastName], [FirstName]
FROM [Employees]
ORDER BY [LastName], [FirstName]")
public class Employees : Query
{
public int Id { get; set; }
}
When you remove programming specific terms (i.e. I removed Select, Entity and renamed Sql to Query). The classes become more readable. Now their names infer only specific information (i.e. this is about an employee). The implementation that it uses SQL or represents an entity pattern is irrelevant. That information should go into the class comments not it's name.
In the future, you will have a bug. Which description is easier to understand, and a result easier to find in the source code.
Employee John Smith is not an active member of Employees.
or
EmployeeEntry John is not an active member of SelectEmployee
That's just an example, but later when you're using those classes the code becomes difficult to read. A sea of terms that aren't relevant to what the code is doing.
Best Answer
You can call sprocs via EF no problem, and I expect the speed is going to be comparable.
The question is why would you? The benefit of EF is the automatic mapping of tables to classes and vice versa.
When you us sprocs you bypass all that and indeed for the kind of microsevice api you are talking about you don't tend to have the long persistence and manipulation of objects anyway.
EF is/was sold as the M of MVC, making database interaction without having to learn SQL and muck around with datasets and adaptors.
But for enterprise level stuff where you want to tweak the SQL execution plans, separate out responsibility to a DBA team etc its not always a good fit.