{"id":4576,"date":"2019-11-08T23:09:08","date_gmt":"2019-11-09T04:09:08","guid":{"rendered":"https:\/\/ikriv.com\/blog\/?p=4576"},"modified":"2019-11-08T23:30:07","modified_gmt":"2019-11-09T04:30:07","slug":"unity-container-when-it-is-too-much-magic","status":"publish","type":"post","link":"https:\/\/ikriv.com\/blog\/?p=4576","title":{"rendered":"Unity container: when it is too much magic"},"content":{"rendered":"

“Any sufficiently\u00a0advanced technology is indistinguishable from magic<\/em>”
\nAthur C. Clarke<\/p>\n

While reviewing some code, I stumbled upon a class that receives an ObservableCollection<ILogFormatter><\/code> in the constructor. I discovered that this collection is never explicitly initialized. Instead, it is magically constructed by the Unity container and injected into the class.<\/p>\n

According to the documentation<\/a>, Unity container resolves IEnumerable<T><\/code> to a sequence that contains one object for each registration of type T. ObservableCollection<T><\/code> is not IEnumerable<T><\/code>, but it has a constructor that takes an IEnumerable<T><\/code>, so Unity resolves it recursively.<\/p>\n

Our code used this feature to inject a list of globally-defined formatters into the logger.<\/p>\n

class<\/span> Logger\r\n{\r\n  public<\/span> Logger(ObservableCollection<ILogFormatter> formatters) {...}\r\n}\r\n\r\n...\r\nvar<\/span> container = new<\/span> UnityContainer()\r\n    .RegisterType<ILogFormatter, ParenthesisFormatter>(\"Parenthesis\")\r\n    .RegisterType<ILogFormatter, CurrentTimeFormatter>();\r\n\r\nvar<\/span> logger = container.Resolve<Logger>();\r\nlogger.Log(\"First message\");\r\nlogger.Log(\"Second message\");<\/pre>\n
This prints each message adding parenthesis, courtesy of the first formatter, and current time, thanks to the second formatter:<\/p>\n
03:48:43.928 (First message)\r\n03:48:43.930 (Second message)<\/span><\/pre>\n
Of course, DI containers are designed to “magically” construct our classes like Santa elves, but to my taste, this is too much magic. Not only the reader must be aware of this obscure feature of Unity to understand the code, he also must remember what objects can be constructed, directly or indirectly from IEnumerable<T><\/code>. To top it up,\u00a0 Unity treats IEnumerable<T><\/code> and T[]<\/code> slightly differently.<\/p>\n
I created a sample<\/a> that mimics this code in branch “magic”, and a refactored version where formatter registration is explicit in branch “master”. The refactored code is larger, but is much easier to understand and contains less magic.\u00a0 In refactored populating the list of formatters is explicit:<\/p>\n
class<\/span> DefaultFormatterList \r\n{\r\n  public<\/span> DefaultFormattersList Add<T>() where<\/span> T : ILogFormatter;\r\n  public<\/span> ReadOnlyCollection<ILogFormatter> FormattersList { get<\/span>; }\r\n}\r\n\r\ncontainer.Resolve<DefaultFormattersList>()\r\n  .Add<ParenthesisFormatter>()\r\n  .Add<CurrentTimeFormatter>();<\/pre>\n
Also, in the spirit of the single responsibility principle LoggerWithFormatters<\/code> is a decorator: it takes a plain logger in the constructor and adds the formatters to it:<\/p>\n
class<\/span> LoggerWithFormatters : ILogger\r\n{\r\n  public<\/span> LoggerWithFormatters(\r\n    ILogger upstream, \r\n    IReadOnlyCollection<ILogFormatter> formatters);\r\n}<\/pre>\n
Container registration then looks as follows:<\/p>\n
container\r\n  .RegisterType<DefaultFormattersList>(new ContainerControlledLifetimeManager())\r\n  .RegisterFactory<ILogger>(c =>\r\n       new<\/span> LoggerWithFormatters(\r\n       c.Resolve<ConsoleLogger>(),\r\n       c.Resolve<DefaultFormattersList>().FormattersList));<\/pre>\n
This may look more complicated then the original, but it tells us exactly what is going on: we resolve ILogger interface by creating an instance of LoggerWithFormatters<\/code> and passing some parameters to it.<\/p>\n
By replacing “magic” container feature with explicit formatter list, we achieved a number of important advantages:<\/p>\n