We arguably don't use all that many facilities (maybe 3 or so total), but our process is to create a separate installer for each facility.
We then use a function for each root assembly (we have a few 'root' programs that share some of the libraries) that provides an array of installers to use for that assembly. This function is the only thing that is responsible for knowing which installers to use (and hence which facilities are needed). This is also how we do special things like registering some special type resolvers too and other "special" container setup. We've found this works well. It does separate the knowledge of which facilities are needed from the things needing them, but we don't consider that too much pain, given that we normally want to control the way the facility gets set up in one shared location anyway. Kelly On Mon, Apr 30, 2012 at 12:44 AM, IanYates <[email protected]> wrote: > Sounds interesting. I can see merits in all of the approaches > although attributes don't seem to be used much in Windsor so it would > be odd to have them for this feature and not others (at least I > haven't used attributes for anything Windsor-related - I'm pretty new > to Windsor and DI in general though). > > The declarative interface-based way of specifying facilities does seem > nice at first glance but may have some problems. If the project that > has my composition root doesn't know anything at all about a facility > "F", how can Windsor know to create it for the installer? What if two > installers want the same facility but want it created in different > ways? > In that light, Hammet's suggestion may be best, so long as all of your > installers play along. I'm a one-man show for the project where I'm > using Windsor for the first time so I've kept my installers pretty > clean with each checking with the container to see if it's already > been installed (I had some installers running twice...). This works > well for me but would require a little more discipline in a team > (maybe using common base classes for installers). > > The declarative one, maybe with some extra method declared on the > generic interface, could be the best of both worlds if the method > implementation's job was to offer a way of registering the facility if > it didn't already exist. > > Cheers, > Ian > > On Apr 30, 2:02 pm, hammett <[email protected]> wrote: >> It's a tough problem.. One thing you could try is to check during >> setup if the facility you need is already installed and either throw >> an exception if it's not, or install it yourself.. >> >> thoughts? >> >> >> >> >> >> On Sun, Apr 29, 2012 at 7:53 AM, Anthony Johnston <[email protected]> wrote: >> > ok.. what about an attribute? >> >> > or am I missing a trick? >> >> > On Apr 18, 2:14 pm, MrAntix <[email protected]> wrote: >> >> Setting up Installers for reuse along side a component which may or >> >> may not required facilities and may in fact require the same ones.. >> >> >> but installers have no way of declaring which facilities they use, and >> >> addfacility will fail if one exists, although I can check >> >> >> so was thinking, would it be good to have the facilities required >> >> declared with the installer? >> >> >> interface IWindsorInstaller<TFacility1, TFacility2> : >> >> IWindsorInstaller >> >> >> Windsor could determine whether or not its already added >> >> >> Could use the same pattern as Tuple for the type parameters or a Tuple >> >> its-self? >> >> >> interface IWindsorInstaller<Tuple> : IWindsorInstaller >> >> >> so.. >> >> >> public class SomeServiceInstaller : >> >> IWindsorInstaller<Tuple<TypedFactoryFacility, MyFacility>> >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Castle Project Development List" group. >> > 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 >> > athttp://groups.google.com/group/castle-project-devel?hl=en. >> >> -- >> Cheers, >> hammetthttp://hammett.castleproject.org/ > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > 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-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. 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-devel?hl=en.
