Circular Dependency

[MattNorman]

I have recently made the switch to .NET Core and am using the built in DI for my classes.

I currently have a circular dependency and not really sure on the best way to resolve it.

I have the following classes:
LoginControl (ActionFilter) - Used to check that a user has been authenticated
SessionManager - Used to read/write from session
BLErrorLog - Used to read/write error log data
DAErrorLog - Used to read/write error log data

The DAErrorLog class in this case is dependent on the SessionManager class to retrieve user data for logging. This then created a circular dependency and causes the build to fail.

I'm not sure how to resolve this as the DAErrorLog needs to be able to get data from the session.

Does anyone have any suggestions?

 

[Skydiver]

Why pull the data from the SessionManager when it's a logger? Data should be pushed to loggers. Loggers should be relatively dumb and not know much about the context in which they are called. Perhaps push the needed information into the constructor of the logger, or push the data into the loggers method call.

 

[MattNorman]

Why pull the data from the SessionManager when it's a logger? Data should be pushed to loggers. Loggers should be relatively dumb and not know much about the context in which they are called. Perhaps push the needed information into the constructor of the logger, or push the data into the loggers method call.

I will see if I can get this to work. The reason I had it this way is that the DAErrorLog class has methods in it that also write to the log if there is an error. The logs are written with username and IP address which is why a SessionManager instance is passed to it

 

[Skydiver]

Yes, the best approach is to break that dependency. Your logger should not know details of your session manager.

If you absolutely cannot break the dependency then the next best thing to do is declare an interface in another assembly. That interface has the required shape to make it look like the session manager. Your logger then just has a dependency on that interface and its assembly instead of the session manager. You session manager then implements that interface (and also has a dependency on that other assembly).