Thanks Luke, Jonathon for the reply. Fortunately that's the approach we have been taking, using factories and not relying on the container's API. Hopefully switching between DI framewroks will be easy. But do you think it's a bad idea to have each assembly define its own IWindsorInstaller, instead of a big installer at the Composition Root? Or, should we have multiple installers but keep them in the assembly that contains the Composition Root? Currently our installers are defined in their respective assemblies and it may be possible for developers to reference the container API without us knowing...
Thanks, On Wednesday, December 31, 2014 4:31:55 AM UTC-8, Jonathon Rossi wrote: > > Hi Ali, > > I agree with Luke that as much effort as possible needs to go into keeping > the container implementation details out of your application code, it helps > for many reasons not just if you decide to change container. One of the big > anti-patterns I see people getting trapped into is injecting Castle's > IKernel or IWindsorContainer directly into their application code to > directly call the container's Resolve or GetHandlers methods, you really > want to be using factories for this sort of thing. A comment I read ages > ago is you should treat your container like Hollywood does actors, don't > call it it'll call you. You should just about never see Windsor being used > in unit tests, otherwise your coupling is too high. > > With that aside, depending on a third party library in any capacity > introduces some level of coupling and risk as you still have to implement > and test all that work at the composition root and everything else around > the sides. As far as I know Hammett, Henry and the Castle Stronghold team > no longer offer commercial support or consulting, and I'm not aware of > anyone that provides a Castle specific offering. As Luke mentioned there > are a few of us that are available on the mailing list and quite a few also > on StackOverflow. > > Unfortunately (or maybe fortunately) sometimes we all get busy, so my > advice to getting a quicker response is to isolate the problem you are > having from your application you can't share and try to reproduce it with a > code snippet or little demo project you can share. > > At the end of the day our source code is completely open, was started over > a decade ago and contains no magic, so there are a lot of people out there > that understand what Windsor does internally so you should never be in a > position you couldn't fix a problem yourself with some guidance. > > On Wed, Dec 31, 2014 at 6:32 PM, Luke Hutton <[email protected] > <javascript:>> wrote: > >> I wouldn't worry about "commercial" support, this mailing list or stack >> overflow should be sufficient if you have any challenging questions. >> >> If you decouple your code from use of a specific container, you should >> fairly easily be able to swap it out with whatever DI framework you wish to >> use. >> >> Read up on Mark Seemann (author of Dependency Injection in .NET >> <http://manning.com/seemann/>): >> >> "A DI Container should only be referenced from the Composition Root. All >> other modules should have no reference to the container." >> >> i.e. Ideally there should be minimal change when swapping out containers. >> Stick to constructor injection, etc. and you should be fine. >> >> >> On Tue, Dec 30, 2014 at 5:27 PM, <[email protected] <javascript:>> wrote: >> >>> Hi, >>> >>> We are planning to use a Dependency Injection framework in our projects >>> across our company. At this stage we are trying to decide which framwork to >>> use. So far and in terms of functionality we prefer Castle Windsor to other >>> options like Microsoft Unity. But the big problem from the corporate point >>> of view seems to be the question of commercial support. >>> >>> So far we have had some technical problems that we solved using the >>> material available online, but we are concerned that if we make a >>> commitment to convert all of our codebase but later encounter another big >>> technical problem we might not be as lucky. Is there any company out there >>> that offers help and support services for Castle Windsor? >>> >>> Thanks, >>> Ali Lahijani >>> >>> *The information contained in this message is the sole and exclusive >>> property of **iHerb Inc.** and may be privileged and confidential. It >>> may not be disseminated or distributed to persons or entities other than >>> the ones intended without the written authority of **iHerb Inc.* *If >>> you have received this e-mail in error or are not the intended recipient, >>> you may not use, copy, disseminate or distribute it. Do not open any >>> attachments. Please delete it immediately from your system and notify the >>> sender promptly by e-mail that you have done so.* >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Castle Project Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] >>> <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> Visit this group at http://groups.google.com/group/castle-project-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Cheers, >> >> Luke Hutton >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/castle-project-users. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Jono > -- *The information contained in this message is the sole and exclusive property of **iHerb Inc.** and may be privileged and confidential. It may not be disseminated or distributed to persons or entities other than the ones intended without the written authority of **iHerb Inc.* *If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it. Do not open any attachments. Please delete it immediately from your system and notify the sender promptly by e-mail that you have done so.* -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/castle-project-users. For more options, visit https://groups.google.com/d/optout.
