One question though regarding registration of components via XML config versus Windsor Installers....
In our previous projects, we had this massive config file with numerous components registered in no particular order. It just seemed to work (Component A depended on Component C but component A was registered before component C). Are installers the same way (they just work without regard to order) or must you invoke the installers based upon your class dependency graph? Thanks for the great tips. On Wednesday, September 12, 2012 2:37:40 AM UTC-5, Berke Sokhan wrote: > > Blog post was a good answer in principle but, I want to add in my > experience that gethering installers into one project instead of > disturbuting to their target libraries is more managable. > > If you gather all installers (but keeping in different files for their > targets) in one project, you dont have to distribute Castle dll references > all over your projects. And when you update with a new castle version > making changes become easier (I know NuGet makes it easy to update across > different projects, but still...) And when you want to change your > container, or its lets say Castle IWindsorInstaller interface signature > changed making changes will be easier... > > A step towards architectural-POCO you may say :) > > 2012/9/12 Krzysztof Kozmic <[email protected] <javascript:>> > >> Does that answer the question? >> http://kozmic.pl/2010/08/10/ioc-patterns-ndash-partitioning-registration/ >> >> -- >> Krzysztof Kozmic >> >> On Wednesday, 12 September 2012 at 9:37 AM, Scott_M wrote: >> >> We are writing a .NET 4.5 WCF service hosted as a Windows NT service and >> plan to use latest castle windsor / wcf facility for dependency injection. >> The WCF service will have multiple dependencies: >> >> 1. Business Logic Components (INT and IMPL assemblies) >> 2. Data Access Layer Components (INT and IMPL assemblies) >> 3. Logging Components (INT and IMPL assemblies) >> 4. Various utilities (INT and IMPL assemblies) >> >> For component registration, we have used xml configuration for similar >> projects in the past. However, this was slow, tedious, fragile, and not >> very re-usable for subsequent projects. What is best practice for >> structuring installers for a project of this nature? Do you write one >> giant installer project to cover 1-4? Do you write separate installers for >> each assembly implementation? How do you deal with installer dependencies >> so they are installed in the proper order? How do you prevent from >> installing a component twice? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/castle-project-users/-/iVTa2_kh6DkJ. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/castle-project-users?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Users" group. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/castle-project-users?hl=en. >> > > > > -- > Berke SOKHAN. > > http://twitter.com/berkesokhan > http://blog.berkesokhan.com > http://www.birliktegelistir.com/editors.aspx > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/castle-project-users/-/Ed_1reDeVc4J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
