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]> 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]> 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]. >> 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. >> > > > > -- > 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]. > 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. > -- Jono -- 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.
