Iniezione delle dipendenze con soluzione Entity Framework di livello n

Attualmente sto progettando una soluzione a più livelli che utilizza Entity Framework 5 (.net 4) come strategia di accesso ai dati, ma sono preoccupato su come incorporare l'integrazione delle dipendenze per renderla testabile / flessibile.

La mia attuale configurazione della soluzione è la seguente (la mia soluzione si chiama Alcatraz):

Alcatraz.WebUI : un progetto webform asp.net, l'interfaccia utente front-end, i progetti di riferimento Alcatraz.Business e Alcatraz.Data.Models .

Alcatraz.Business : un progetto di libreria di classi, contiene la logica aziendale, i progetti di riferimento Alcatraz.Data.Access , Alcatraz.Data.Models

Alcatraz.Data.Access : un progetto di libreria di classi, ospita AlcatrazModel.edmx e AlcatrazEntities DbContext, fa riferimento a progetti Alcatraz.Data.Models .

Alcatraz.Data.Models : un progetto di libreria di classi, contiene POCO per il modello Alcatraz, nessun riferimento.

La mia visione del funzionamento di questa soluzione è che web-ui crei un'istanza di repository all'interno della business library, questo repository avrebbe una dipendenza (tramite il costruttore) di una stringa di connessione (non un'istanza di AlcatrazEntities ). Il web-ui conoscerebbe le stringhe di connessione del database, ma non che fosse una stringa di connessione del framework di entità.

Nel progetto Business:

public class InmateRepository : IInmateRepository
{
    private string _connectionString;

    public InmateRepository(string connectionString)
    {
        if (connectionString == null)
        {
            throw new ArgumentNullException("connectionString");
        }

        EntityConnectionStringBuilder connectionBuilder = new EntityConnectionStringBuilder();

        connectionBuilder.Metadata = "res://*/AlcatrazModel.csdl|res://*/AlcatrazModel.ssdl|res://*/AlcatrazModel.msl";
        connectionBuilder.Provider = "System.Data.SqlClient";
        connectionBuilder.ProviderConnectionString = connectionString;

        _connectionString = connectionBuilder.ToString();
    }

    public IQueryable<Inmate> GetAllInmates()
    {
        AlcatrazEntities ents = new AlcatrazEntities(_connectionString);

        return ents.Inmates;
    }
}

Nell'interfaccia utente web:

IInmateRepository inmateRepo = new InmateRepository(@"data source=MATTHEW-PC\SQLEXPRESS;initial catalog=Alcatraz;integrated security=True;");

List<Inmate> deathRowInmates = inmateRepo.GetAllInmates().Where(i => i.OnDeathRow).ToList();

Ho alcune domande correlate su questo design.

1. Questo progetto ha senso anche in termini di funzionalità di Entity Frameworks? Ho sentito che il framework Entity utilizza già lo schema Unità di lavoro, sto semplicemente aggiungendo un altro strato di abstract inutilmente?

2. Non voglio che il mio web-ui comunichi direttamente con Entity Framework (o che faccia riferimento ad esso), voglio che tutto l'accesso al database passi attraverso il livello aziendale, perché in futuro avrò più progetti che utilizzano lo stesso livello aziendale (servizio Web, applicazione Windows, ecc.) e voglio mantenerlo / aggiornarlo facilmente avendo la logica aziendale in un'area centrale. È un modo appropriato per raggiungere questo obiettivo?

3. Il livello aziendale dovrebbe contenere anche repository o dovrebbe essere contenuto nel livello di accesso? Se dove sono a posto, passa una stringa di connessione di una buona dipendenza da assumere?

Grazie per aver trovato il tempo di leggere!