How to split out a service layer

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).

Here is my two cents worth, I tried to find support for my "WCF is just an interface" on google but have had no luck. I will try again this evening if I get the chance.

The way I was taught and have always approached this is that WCF is just another interface (using the term interface in the way that "GUI" uses it not as the .Net keyword), specifically a way to access code over a network (or internet etc.) I always have a separate class library(s) that the WCF service delegates to for all functionality not related to WCF.

That class library is designed to be usable from any .Net code on the same machine.

The WCF service will do the work to make the library consumable by a variety of languages over the wire. It may translate .Net types to more generic types, lists to arrays for example, or it may add compression for performance reasons.

So if you are consuming the library from .Net code on the same machine I would go directly against the class library. You may want to install this in the GAC for version control.

Of course if the service is stateful then you may want to code against it for simplicity's sake.

Edit. I thought of another reason you might want to bypass WCF locally. For performance reasons a WCF Client should never be "chatty" it is better to make fewer calls that pull in more data, running against a DLL this limitation is not important. So your class library could expose methods that you would not want to expose over WCF.