jeudi 24 mai 2018

Logic in the Composition Root

Is it considered bad practice to put business logic in the composition root? I have an application where an event occurs, either from the UI or by receiving a message on a socket from another application. This event triggers a complex set of steps that involve several other unrelated classes. For example, when the message arrives that a call has started, we might want to send a socket message to a third application, update some hardware, play a sound to the user, and update the UI. Obviously the message processing object can't know about all these other classes. The only place that does is the composition root. So the composition root subscribes to the message handler's event with a function (also in the composition root) that does the needed logic with the rest of the classes.

Public Class CompositionRoot
    'Variable declarations would go here

    Public Sub New()
        'Instantiate all the objects

        'Hook an event for what to so when a message is received
        MyMessageProcessor = New MessageProcessor
        AddHandler MyMessageProcessor.MessageReceived, AddressOf OnStartCall
    End Sub

    Private Sub OnStartCall()
        If JurisdictionChecker.CheckJurisdiction Then
            RemoteCallMonitor.SendStateMessage("Active call")

            CallTimer.StartCall()
            Speaker.PlayAlert()
            FootPedal.Enable()
            MainForm.ShowNewCall()
        Else
            ErrorReporter.ReportError("Failed jurisdiction check")
        End If
    End Sub
End Class

Is it a problem to have logic inside the composition root? I thought about making another class for the logic but then that class will have a lot of dependencies, which are pretty much unrelated so I can't just make coarser groups of operations. I would prefer to use Pure DI with no container if possible, but that's not a hard and fast rule.

Aucun commentaire:

Enregistrer un commentaire