tag:blogger.com,1999:blog-15136575.post1463236452403500047..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: EasyNetQ’s Minimalist DI ContainerMike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-15136575.post-14129608357027189452013-12-05T19:14:18.316+00:002013-12-05T19:14:18.316+00:00Mike,
Yeah, I think a simple interface like the...Mike,<br /> Yeah, I think a simple interface like the one I pointed to that we implement with DI of our choice would be a good improvement. Thanks for info!Wayne Brantleyhttps://www.blogger.com/profile/10640873225205821040noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-13769371873467245692013-12-05T09:15:53.821+00:002013-12-05T09:15:53.821+00:00Wayne, you could switch in your own IoC container,...Wayne, you could switch in your own IoC container, although I could probably make it easier than it is. Currently you'd need to implement your own version of RabbitHutch and ComponentRegistration.<br /><br />Yes, switching the serializer is straightforward. See above :)Mike Hadlowhttps://www.blogger.com/profile/15393720749809796178noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-69961029827100556712013-12-05T06:51:26.174+00:002013-12-05T06:51:26.174+00:00Consider a generic interface that lets us wire wha...Consider a generic interface that lets us wire whatever DI framework we want. Like this https://github.com/ServiceStackV3/ServiceStackV3/wiki/The-IoC-container#use-another-ioc-container<br /><br />Also, consider your json serializer default could be the servicestack one that is extremely fast compared to the one you currently use...regardless I assume we can switch that with DI?Wayne Brantleyhttps://www.blogger.com/profile/10640873225205821040noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-45146431435808540702013-11-28T10:20:24.545+00:002013-11-28T10:20:24.545+00:00"imagine you are a happily using AutoFac and ..."imagine you are a happily using AutoFac and suddenly Castle.Windsor appears in your code base, or even worse, you are an up-to-date Windsor user, but EasyNetQ insists on installing an old version of Windsor alongside" this, or a more annoying version of it, is the reason we stopped using NSB and moved to EasyNetQ. The sheer weight of dependencies in NSB really starts to grate after a while.<br /><br />Also, it's strange that you should mention the serializer and error handling as those are the bits that we've changed. We've hacked* a workaround for an issue we hit with changing the serialization and the validation of message types. What we probably need to do is pull out the the error handling as well to fit better with our serialization/validation strategy, but the two things do seem to be pretty tightly coupled.<br /><br />Anyway, keep up the good work.<br /><br /><br /><br />*which sounds better than 'bodged'.Steve Friendhttps://www.blogger.com/profile/01082676456418254427noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-80433277139732561842013-11-26T09:17:59.191+00:002013-11-26T09:17:59.191+00:00Hi Daniel,
Thanks for that. Don't worry, I li...Hi Daniel,<br /><br />Thanks for that. Don't worry, I like a good rant myself :)<br /><br />You make a very interesting point. By essentially inviting users to take an interest in every internal interface I am allowing the surface area of the API to extend to the internals of the application. In your example, you only provide a limited set of extension points that you can more closely control.<br /><br />Interesting to hear that NServiceBus is moving away from this approach. I'm considering moving to a two track version strategy. Something like: The core interfaces of EasyNetQ will be versioned on major numbers, so if you only use IBus or IAdvancedBus you will be guaranteed no breaking changes within a major version number. 'Internal interfaces' are free to change on minor version numbers, so if supply your own dispatcher factory, you should expect to have to change your code on a minor version change.<br /><br />For the time being EasyNetQ is still very much alpha software, I reserve the right to make across the board breaking changes on minor version numbers up to version 1.0. But I'd like to move to version 1.0 in the near future, so I'm very interested to hear about the experiences of more mature libraries like NServiceBus.Mike Hadlowhttps://www.blogger.com/profile/15393720749809796178noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-5198803960644635302013-11-26T08:11:48.827+00:002013-11-26T08:11:48.827+00:00Hy Mike
I just ranted on twitter about this. I jus...Hy Mike<br />I just ranted on twitter about this. I just want to let you know that :D I'm getting sick of container abstractions. These are so leaky abstractions. Every framework/library these days has one and usually their interfaces are so generic and bloated without giving any meaning to the library. The same happens to your abstraction. To keep the APIs related to the things the library is doing I like to have factories and interfaces which allow on certain extension points to hook into the library. Let me give you a concrete example:<br /><br />The distributed event broker I did here https://github.com/appccelerate/appccelerate/tree/master/source/Appccelerate.DistributedEventBroker has an interface called IDistributedFactory. The is the main enabling point for changes (call it seam). We have usually standard implementations of these interfaces or an abstract base class which allows you to hook in specifics. With this you control where the framework can be extended.<br /><br />Let me give you another example for the wild out there were we had to learn by mistake. NServiceBus has a common object builder abstraction which is used everywhere. With that the User can essentially plugin anything. This makes the API breaking at various points. Even NSB will retire from this approach.<br /><br />Hope this helps<br /><br />DanielDaniel Marbachhttp://www.planetgeek.chnoreply@blogger.com