Struttura corretta ed efficiente per un livello di entità?

Sembra che tu stia provando a modellare un insieme di fonti di dati disparate come un singolo modello.

Se è davvero così, la mia opinione è che la creazione di un progetto per rendere l'astrazione è la strada da percorrere.

Dico questo perché hai a che fare con diversi TIPI di fonti. Ad esempio, se tu avessi solo due database potresti mettere un collegamento tra loro e astratto in questo modo.

Tuttavia, hai a disposizione un data warehouse, alcuni servizi Web e Active Directory. Non so se ci sarebbe un modo per consolidare tutte queste cose, e anche se ci fosse, potrebbe essere complicato.

Mettere l'astrazione in un progetto separato assicura anche che tu debba cambiare UN posto quando le entità cambiano. Inoltre ti assicura di nascondere i dettagli di ciò che accade dietro le quinte del tuo front-end. Questo può essere importante, in particolare quando devi aggiungere qualcos'altro (non se - con molte fonti qualcos'altro verrà sicuramente dopo)

Avere un assembly separato per l'accesso ai dati è una buona idea in questo caso e rende più semplice puntare un progetto di test separato per testare in modo più pulito il livello di accesso ai dati. È possibile sviluppare i modelli di entità come classi semplici e quindi utilizzare i servizi per popolarli. Potresti dare un'occhiata a Entity Framework Code First per l'accesso al database in quanto si allontanerà dalla dipendenza .edmx e manterrà le tue classi di entità più pulite.

C'è un tutorial di Scott Guthrie sull'uso di Code First con i database esistenti.

Ho già utilizzato il modello di repository in un progetto che sembra molto simile a questo. Ho catturato le entità come semplici classi e quindi per le entità che sono state archiviate in SQL ho usato Entity Framework Code First per generare le tabelle in SQL per me. Inoltre, se le tue informazioni saranno archiviate in più database, avrai solo bisogno di una classe DBContext per ogni origine dati. L'utilizzo del modello di repository ti consentirà di puntare a qualsiasi fonte per popolare ogni repository di entità.

Per quanto riguarda i servizi web, in genere li divido in un altro progetto per creare una divisione fisica tra un livello di servizio e uno strato dati.

Quindi in questo scenario avrei 2 progetti. Uno per il livello dati (questo implementerebbe il pattern del repository, includerà entità correlate e gestirà CRUD in datastore usando EF o ADO.Net), e uno per il livello di servizio (questo parlerà con il servizio AD, i servizi SharePoint e qualsiasi altro servizi. Conterrà anche le entità correlate per questi servizi).