That was why in this case I would suggest creating a method to allow the
user to register interface types which they would like to be their
registerable interfaces, I wouldn't want to force that on users either, just
in my case wasn't necessary since my interface exists in the same project as
the functionality :) .



On Thu, Jan 21, 2010 at 8:29 AM, Ayende Rahien <[email protected]> wrote:

> I wouldn't like to have something like this for the simple reason that I
> want to avoid forcing people to implement my interface.
>
> On Thu, Jan 21, 2010 at 4:21 PM, Richard Fleming <[email protected]>wrote:
>
>> Just as an alternative method to a [Service] attribute I do something
>> along the following in most of my projects now:
>>
>>     public interface IRegisterable { }
>>     public interface IRegisterableWithFactory : IRegisterable { }
>>
>>
>>     public static class WindsorExtensions
>>     {
>>         public static BasedOnDescriptor FirstInterfaceOnType(this
>> ServiceDescriptor serviceDescriptor)
>>         {
>>             return serviceDescriptor.Select((type, baseType) =>
>> GetInterfacesOnType(type));
>>         }
>>
>>         private static IEnumerable<Type> GetInterfacesOnType(Type type)
>>         {
>>             var interfaces =
>> type.GetInterfaces().Except(type.BaseType.GetInterfaces());
>>             return interfaces.Count() == 0
>>                        ? (typeof(object).Equals(type.BaseType) ? null :
>> GetInterfacesOnType(type.BaseType))
>>                        : new[] { interfaces.First() };
>>         }
>>     }
>>
>>         public DefaultContainer AddRegisterableComponentsFrom(Assembly
>> assembly)
>>         {
>>             return
>> AddRegisterableComponentsFrom(assembly.GetTypes().ToList());
>>         }
>>
>>         public DefaultContainer
>> AddRegisterableComponentsFrom(IEnumerable<Type> types)
>>         {
>>             Register(
>>                 AllTypes.Pick().From(from t in types
>>                                      where !t.IsClass && typeof
>> (IRegisterableWithFactory).IsAssignableFrom(t)
>>                                      select
>> t).WithService.FirstInterfaceOnType().Configure(
>>                     c =>
>> c.Attribute("instance-accessor").Eq("Instance")));
>>
>>             Register(
>>                 AllTypes.Pick().From(from t in types
>>                                      where t.IsClass && !t.IsAbstract &&
>> typeof(IRegisterable).IsAssignableFrom(t) &&
>> !typeof(IRegisterableWithFactory).IsAssignableFrom(t)
>>                                      select
>> t).WithService.FirstInterfaceOnType());
>>             return this;
>>         }
>>
>>
>> (DefaultContainer is my class inheriting from WindsorContainer where I
>> configure facilities outside of configuration)
>>
>>
>> What I liked about this method was it allowed me to control
>> auto-registration by having a custom interface defined (and typically
>> creating an AbstractComponent or something of that sort which implements
>> IRegisterable).
>>
>> Just thought I would throw this out there as another alternative, I was
>> thinking along the lines of possible if there was a way to register a
>> interface type(s) as the "auto-registering" (IRegisterable in this case)
>> within the container to make the functionality more general across multiple
>> projects.
>>
>> Thanks,
>> Rick Fleming
>>
>>
>>
>>
>>
>>>  >    - Consider adding attributes like [Service] - to make auto
>>>> registration
>>>> >    easier.
>>>>
>>>> +1
>>>>
>>>> >    - Convention based registration for fluent stuff
>>>> >       - IFoo -> Foo
>>>> >       - IFoo -> FooImpl
>>>> >       - IFoo -> FooService
>>>>
>>>> - I'm not sure what you mean by that...
>>>>
>>>>
>>> contianer.AddAssembly("foo");
>>>
>>> - scan for all interfaces
>>> - for each interface, look for a matching type based on the following
>>> naming conventions, if exists, register it.
>>> - same for types marked as [Service] that implement only one interface
>>> - if there is more than one interface implemented, require a interface
>>> parameter on the attribute.
>>>
>>
>>
>>
>>  --
>> 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]<castle-project-devel%[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]<castle-project-devel%[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.


Reply via email to