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