Stefan Glienke, do you foresee any real issues one might encounter if he/she use the DI container linked below? The obvious issue would be that it doesn't support interfaces. But in my case I think using class inheritances with abstract methods can overcome that (https://stackoverflow.com/a/2279242/133516)
Stefan Glienke, do you foresee any real issues one might encounter if he/she use the DI container linked below? The obvious issue would be that it doesn't support interfaces. But in my case I think using class inheritances with abstract methods can overcome that (https://stackoverflow.com/a/2279242/133516)
Just in case you might ask - I believe spring4d is excellent, except that the only thing I need is DI so I don't want to rely on such a huge library ;)
https://github.com/danieleteti/delphidicontainer
Just in case you might ask - I believe spring4d is excellent, except that the only thing I need is DI so I don't want to rely on such a huge library ;)
https://github.com/danieleteti/delphidicontainer
Relying on the Spring4d Container doesn't mean you rely on "such a huge library". You'd only rely on the Container.
ReplyDeleteWhy choose a different wheel that has 24 commits over 2 years time of which the most recent one is 2 years old?
ReplyDeleteMaybe I should mention that the DI container you are contemplating on has a whopping 16 test cases and 2 "Button1Click" style example projects?
Not to diminish the work of Daniele (he has great stuff at for instance github.com - danieleteti/delphimvcframework is awesome), but if you need a DI container just go for Spring4D.
DI and containers are two different things. DI is most often referred to in the context of unit testing, so most people seem to associate DI with that. At least you're past that hurdle! But you don't need to use a container to use DI. If you don't use a container, Delphi won't link in the code. So you're not hauling around a bunch of dead code in your app.
ReplyDeleteWhy don't you share what you're trying to accomplish rather than pointing people to another library and asking for opinions on how they compare?
Nick Hodges The JCL project analyzer shows that it adds 23 units and over 3MB size to the EXE output, using the UseContainer sample project.
ReplyDeleteJeroen Wiert Pluimers I choose it because it does the work (except not supporting interfaces) and lightweight. Re. the commits, maybe because it has only 493 lines of code?
ReplyDeleteEdwin Yip both articles discuss DI in the context of containers. How can you possibly separate the two by reading them?
ReplyDeleteTry reading "Dependency Injection in .NET" an outstanding Book by Mark Seemann. Roughly half is about DI and half is about containers. At one point, even Seemann admits that the code needed for DI containers is relatively small.
Nick Hodges has a new book out that tackles this topic as well. It's focused more on Delphi and doesn't go into nearly as much detail as Seemann (he does cite Seemann and suggests that book for more details), but I had no problem understanding Seemann's book -- the language differences are really minor because the two languages are so semantically similar.
All that said, you still haven't said what the problem is you're trying to solve or what you're trying to avoid (aside from what you're alleging is code bloat from unneeded classes).
David Schwartz Maybe I'm misunderstanding you, but are you mixing up a generic container (such as TObjectList) with a 'dependency injection container' (which is defined as "A Dependency Injection Container is an object that knows how to instantiate and configure objects.", and is implemented in Spring.Container.pas in Spring4D)?
ReplyDeleteWhat I'm trying to achieve is actually obvious - 'decoupled modules', by avoiding dependencies between classes, using the established 'Inversion of Control' concept, which is then can be implemented by 'Dependency Injection Containers'. And for DI containers, I've got two options: A) Spring.Container.pas in Spring4D by Stephen, and B) DelphiDiContainer linked in the original post, by Daniele.
I think Spring.Container is number 1 in terms of functionality, but since, as I stated above, it adds 23 units and over 3MB file size to my .EXE output, I want to avoid it.
So I instead choose option B, DelphiDiContainer. So far so good, except that it doesn't support interface nor 'service factory' (for implementing lazy loading). I'm OK with the lack of support for 'serfice factory', but I feel a little uncomfortable with the lack of interface support, thus my question here, with the hope of getting thoughtful inputs from you insightful people such as Stephen.
I hope it's clear now :)
/sub
ReplyDeleteWow, Marco subscribed this post, that makes me feel this is not a very dumb question then ;P One more consideration after some more research today - If I use abstract methods instead of interfaces (which is not supported by DelphiDIContainer), I'll would NOT be able to use Delphi-Mocks for testing.
ReplyDeletedelphisorcery.blogspot.com - Supports killing objects
Edwin Yip If you prefer lightweight code, why don't you inject your dependencies manually? DI container is not mandatory for doing DI.
ReplyDeleteSo by now you found 2 things you're missing with two solutions: using Spring4D which adds 3 megabyte emitted code or writing those features yourself.
ReplyDeleteJeroen Wiert Pluimers Good conclusion! Actually I don't quite mind adding 3 megabytes to my output file, it's the 70K lines of source code my program would have to depend on that I fear ;) Especially the compiler crashes from time to time when compiling code with intensive use of generics and anno. methods... But I might change my mind when I finishing reading through all the spring4d samples.
ReplyDeleteLinas Naginionis I'll be appreciated if you point me to an article with example code doing that (DI without a DI container). On the other hand, I wish that approach will be simpler than adding interface support to Daniele's "delphidicontainer". ;)
ReplyDeleteEdwin Yip I totally agree that the compiler should be improved. Even without Spring4D the Delphi compilers crash on generics at seemingly random intervals. I cannot imagine Embarcadero engineers using generics escaping these problems. Maybe they should more rely on Spring4D so they can stress their product more and make it more stable.
ReplyDeleteEdwin Yip I'm certainly no authority on this subject, although from what I can tell from your comments, you still do not understand the difference between "dependency injection" (DI) and "DI Containers". I urge you to read Mark Seemann's book if you want a thorough explanation of it. (As I said earlier, those two articles you referred to don't do it.) I'm not about to try explaining it here (and I doubt I could even do the subject justice anyway). Coding DI (or Inversion of Control) does not require any "container" for anything. It's simply a way of injecting dependencies (ie., instances of objects) into other objects rather than letting the latter objects themselves create the external objects that they depend upon.
ReplyDeleteI think a far better moniker would be "the Trojan Horse" pattern, because that's basically what's going on, only not from a subversive perspective.
/sub
ReplyDeleteDavid Schwartz It seems that I misunderstood you, now I understand. Yes, I know the difference between DI and 'DI container', especially after reading this article today (https://github.com/ninject/ninject/wiki/Dependency-Injection-By-Hand). Thanks David.
ReplyDeletegithub.com - Ninject
Update: so I have converted to Spring4D now :)
ReplyDeleteEdwin Yip Ahh, great job, grasshopper! Nick Hodges has a very similar analogy in his book as well.
ReplyDeleteEdwin Yip you might want to watch my CodeRage 9 video as it touches on these topics
ReplyDeleteyoutube.com - Have You Embraced Your Inner Software Plumber Yet?
David Schwartz Thank you, for sure I'll check it out! After going through all the Spring4D samples, reading tens of related articles, plus reconsidering Daniele's DI container would stop me from using interfaces, I found no reasons not to convert ;) And it's done.
ReplyDelete