Dependency injection with n-tier Entity Framework solution

Question

I am currently designing an n-tier solution which is using Entity Framework 5 (.net 4) as its data access strategy, but am concerned about how to incorporate dependency injection to make it testable / flexible.

My current solution layout is as follows (my solution is called Alcatraz):

Alcatraz.WebUI: An asp.net webform project, the front end user interface, references projects Alcatraz.Business and Alcatraz.Data.Models.

Alcatraz.Business: A class library project, contains the business logic, references projects Alcatraz.Data.Access, Alcatraz.Data.Models

Alcatraz.Data.Access: A class library project, houses AlcatrazModel.edmx and AlcatrazEntities DbContext, references projects Alcatraz.Data.Models.

Alcatraz.Data.Models: A class library project, contains POCOs for the Alcatraz model, no references.

My vision for how this solution would work is the web-ui would instantiate a repository within the business library, this repository would have a dependency (through the constructor) of a connection string (not an AlcatrazEntities instance). The web-ui would know the database connection strings, but not that it was an entity framework connection string.

In the Business project:

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;
    }
}

In the Web UI:

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();

I have a few related questions about this design.

1. Does this design even make sense in terms of Entity Frameworks capabilities? I heard that Entity framework uses the Unit-of-work pattern already, am I just adding another layer of abstract unnecessarily?

2. I don't want my web-ui to directly communicate with Entity Framework (or even reference it for that matter), I want all database access to go through the business layer as in the future I will have multiple projects using the same business layer (web service, windows application, etc.) and I want to have it easy to maintain / update by having the business logic in one central area. Is this an appropriate way to achieve this?

3. Should the Business layer even contain repositories, or should that be contained within the Access layer? If where they are is alright, is passing a connection string a good dependency to assume?

Thanks for taking the time to read!

Answer 1

The way you are doing DI is wrong.

First, the connection string belongs in the data layer. Or in the web.config file.

The next abstraction you will be dealing with is the DbContext, not a connection string. Your repositories should not know about connection strings. Your business logic will not know about DbContext etc.

Your UI will have no idea and will not instantiate anything related to EF.

Concrete answers to your points:

1. Do not add abstractions, until you are very familiar with EF. It already adds good abstractions like UoW, queries, using POCOs etc.

2. For DI to work, you have a Composition Root which references all components needed. This might or might not be in the WebUI project. If it isn't, you should expect that it does not reference EF or any other data related tech.

3. Stop right here. Stop adding abstractions over abstractions. Start with direct and 'naive' architecture and develop it over time.

Abstractions are a tool to deal with complexity. Absence of complexity means no abstractions needed (yet).

Answer 2

A few quick comments. I personally probably wouldn't pass a connection string. If anything I would try and create interfaces maybe for the repositories and just pass the interfaces around? Have the repositories implement or expose a IOW interface.

This way it doesn't event need to be a database that implements your repositories. they could be an in memory cache, or anything. Maybe then you could use some sort of dependancy injection framework to instantiate these even?

So in answer to some of your questions:

1. Yes, I think it's ok
2. I would still have the UI reference the EF project and the buisness layer reference interfaces that the EF repository layer implements. That way other projects could still use the same assemblies but they have the flexibility to swap out if desired?
3. hmmm, Probably the repositories in the access layer but implementing an interface definition exposed in the business layer??

These are just some thoughts to mull over.