Thanks for the quick responses everyone! As for the reason for so may many assemblies. It's really about separation of concerns. I realize each "layer" could be in the same assembly but I prefer to maintain hard boundaries where possible (otherwise, one using statement could break the pattern). Domain for core business logic, Console for presentation (could be web service, ASP.NET, Windows Forms, whatever), Service for repository implementations, and a common framework to glue it all together.
This approach came in handy just this morning where I was creating unit tests for our interceptors. I created a unit test service installer that would register stub services from my unit test assembly. To load the installer, I simply updated the IWindsorInstaller in the app.config to work with the unit test implementation (same approach that I described earlier). In retrospect, I don't think allowing loading from 2 different assemblies would be wise. I think this "default installer" pattern works much better. Loading from 2 assemblies would be fine when using auto registration but the whole thing falls apart when you switch to specifying each component line-by-line. Actually, it would be impossible since it would require 2 way dependency between your assemblies. eg The framework knows about types in the domain layer and the domain knows about types in the framework. It just wouldn't work. On Sep 27, 10:37 am, Roei Bar <[email protected]> wrote: > you can do it preaty easy. > > use AllTypes.FromAssemblyInDirectory. > > then, just device the assemblies into seperate directories. > > On Mon, Sep 27, 2010 at 3:13 AM, José F. Romaniello > <[email protected]>wrote: > > > I am used to have a separated assembly called GuyWire, with various > > implementations of IWindsorInstaller and the container bootstrapping. > > In order to have strongly typed registration, this assembly reference > > almost any assembly in the solution, but no one references to the guywire. > > The trick is very simple, have a a common interface named IGuyWire... , the > > guywire assembly has as output path the startup project... and the startup > > project does a load in runtime... > > > more details here: > >http://fabiomaulo.blogspot.com/2009/11/guywire.html > > <http://fabiomaulo.blogspot.com/2009/11/guywire.html> > >http://jfromaniello.blogspot.com/2009/11/chinook-media-manager-guywir... > > <http://jfromaniello.blogspot.com/2009/11/chinook-media-manager-guywir...> > > > 2010/9/26 John Simons <[email protected]> > > > Regardless of the number of assemblies, I think it would be beneficial to > >> separate the assemblies registration(assemblies to scan) from the actual > >> component registration, thoughts? > > >> Cheers, John > > >> On 27/09/2010, at 7:49, Krzysztof Koźmic <[email protected]> > >> wrote: > > >> > 1. What real benefit do you have from that many assemblies? From what > >> you describe it looks like you need two: one for UI one for everything > >> else. > > >> > 2. See this: > >>http://stw.castleproject.org/Windsor.Registering-components-by-conven... > > >> > if none of provided approaches suits you rethink your architecture or > >> use Select and provide your custom logic. > > >> > HTH, > >> > Krzysztof > > >> > On 27/09/2010 2:00 AM, James wrote: > >> >> Hi, > > >> >> I've been trying to get auto registration to work on my work but I've > >> >> run into a bit of a snag when it comes to breaking out my code into > >> >> separate assemblies. > > >> >> I have 4 assemblies in a pretty straight forward setup: > >> >> -Domain > >> >> (Service Interfaces, domain model) > > >> >> -Framework > >> >> (Service locator, Base service interface, interceptors, Windsor > >> >> installer) > > >> >> -Services > >> >> (Service Implementations, all services implement framework base > >> >> service) > > >> >> -Console > >> >> (Presentation, references domain and framework) > > >> >> This setup works fine when using XML configuration (since you specify > >> >> the assembly for each component). However, this setup will not work > >> >> with auto registration because you can only load one outside > >> >> assembly. > > >> >> Is there any way I can use the fluent API to say something like "load > >> >> interfaces from my domain assembly and register them with > >> >> implementations from my service assembly?". > > >> >> Here is the code I'm calling from the Framework layer, somehow I need > >> >> to load the Service assembly: > > >> AllTypes.FromAssemblyNamed("Domain").BasedOn<Framework.IService>().WithService.FromInterface() > > >> >> Thanks > >> >> James > > >> > -- > >> > 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]. > >> > To unsubscribe from this group, send email to > >> [email protected]<castle-project-users%[email protected]> > >> . > >> > 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]. > >> To unsubscribe from this group, send email to > >> [email protected]<castle-project-users%[email protected]> > >> . > >> 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] > > . > > To unsubscribe from this group, send email to > > [email protected]<castle-project-users%[email protected]> > > . > > 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]. 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.
