I've been reading up on DI and from what I can gather, the structure your VS solution should be as follows:

Web (UI) Project references:

* Data Access (\*scratches head)
* Business Logic
* DTO

Business Logic Project references:

* DTO

Data Access Project references:

* Web (\*scratches head again)
* Business Logic
* DTO

Plus, the interfaces for concrete implementations should be kept in the Business Logic project which the DA will implement in a concrete class. 

The "classic" 3 layer structure is:

Web references

* Business Logic

Business Logic references: 

* DA

(With DTOs referencing all layers).

What I'm trying to understand with the DI structure is, I appreciate it seems to help with separating each module for testing and not invoking concrete classes within classes - but with the way the references are set up within the project, there feels like there's a tight coupling with the layers? The UI has a hard reference to both the DA and BL (and therefore has to instantiate both the BL class and a DA class that implements the interface that the BL accepts as part of the constructor injection). 

It somehow feels wrong the UI now has references to both BL and DA. If I wanted to say implement IMessage with a SendMessage() method, (swapping from an SMTP server to say a SMS provider), I'd still have to invoke a DA class in the UI and pass it into the BL. Feels wierd?!

It looks like the UI decides what implementation of data it wants via invoking an instance of a BL logic class, which accepts an concrete implementation of a data access class in the web layer? 

I'm just trying to completely clear my head of the classic n layer structure in VS and be open to how handing this in the UI is good (The UI should only be worried about the UI right?). I think I just need that light bulb to go off via a simple explanation. If you can help, it would be very much appreciated!

P.S - I'm working my way through Mark Seemann's Dependency Injection in .NET book at the moment, so my head is a bit fried!