Dependency Injection - Visual Studio layer structure for ASP.NET

Question

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!

Answer 1

It all depends on where you put your factories and how much responsibility you give to each of them. For instance, if, in you have the following factories

' In the data access layer project
Public Class DataAccessFactory()
    Implements IDataAccessFactory

    Public Sub New()
        ' ...
    End Sub

    ' ...
End Class

' In the business layer project
Public Class BusinessFactory()
    Public Sub New(daFactory As IDataAccessFactory)
        ' ...
    End Sub

    ' ...
End Class

Now, when you create a business factory in the UI, you first have to create a data access factory, in the UI layer, so that you can inject it into the business factory. So, in that situation, the UI layer needs to reference both the business and the data access layer projects. However, you could also give more responsibility to the business factory, like this:

Public Class BusinessFactory()
    Public Sub New()
        _daFactory = New DataAccessFactory()
    End Sub

    Private _daFactory As IDataAccessFactory

    ' ...
End Class

Now, the UI layer doesn't get to decide which data access layer it will use, but it also no longer needs a reference to the data access layer project. In the second example, only the business layer project requires a reference to the data access layer project.

It's a little less flexible, since you'd need to implement a separate business factory for each data access factory that you want to support, but you can make it more flexible by implementing it like this:

Public Class BusinessFactory()
    Implements IBusinessFactory

    Public Sub New()
        _daFactory = NewDataAccessFactory()
    End Sub

    Private _daFactory As IDataAccessFactory

    Protected Overridable Function NewDataAccessFactory() As IDataAccessFactory
        Return New DataAccessFactory()
    End Function

    ' ...
End Class

Notice, the NewDataAccessFactory method is overridable. So now, when you need to use a different data access factory, you can override that same method without having to duplicate the rest of the factory logic. For instance:

Public Class XmlBusinessFactory()
    Inherits BusinessFactory

    Public Sub New()
        MyBase.New()
    End Sub

    Protected Overridable Function NewDataAccessFactory() As IDataAccessFactory
        Return New XmlDataAccessFactory()
    End Function
End Class

Of course, all of the logic (non-factory) classes are still fully injectable. It's only the factory classes which are slightly less flexible. But, on the plus side, not only does your UI layer no longer need to reference the data access layer, but it also makes it easier to instantiate your factory objects. All you need to do is create the factory you need, rather than all its dependency factories too.

If you ever needed to make the factory's dependencies injectable, such as for unit testing your factory, you could still do so by making an injectable derived class, like this:

Public Class InjectableBusinessFactory()
    Inherits BusinessFactory

    Public Sub New(daFactory As IDataAccessFactory)
        MyBase.New()
        _daFactory = daFactory
    End Sub

    Private _daFactory As IDataAccessFactory

    Protected Overridable Function NewDataAccessFactory() As IDataAccessFactory
        Return _daFactory
    End Function
End Class

So, while doing so requires an extra step, it does mean that following this design does not mean that you are painting yourself into a corner. In the end, you need to weigh the pros-and-cons and pick what works best in your situation. I recommend trying implementing your factories both ways so that you can get a feel for both methods.

Answer 2

You can separate your interfaces from its implementation by putting them in a different assembly and having all your DI configurations in a separate assembly. If you put all the DI configurations in a different assembly then your UI layer will no longer need to reference all the other layers. You can then also easily switch the configuration assembly to quickly change the DI configuration without affecting UI layer.