Ok, if you have to do this for every Type thats a lot of configuration
overhead. I thought you have one generic Repository implementation
that will be used for all types of entities.
Am 09.03.2010 um 11:42 schrieb joniba <[email protected]>:
Belvasis, I see what you're saying. It looks like that could work. The
downside of this technique, though, is that I have to duplicate these
two registrations for every single repository (there are over 30 right
now). Now think if I had a 3-decorator chain (that's the plan): I
would have to write 4 entries for each repository. E.g.,
1. Register validation decorator for Document-type with inner to
security decorator
2. Register security decorator for Document-type with inner to
transaction decorator
3. Register transaction decorator for Document-type with inner to
Document repository
4. Register Document repository
For 30 repositories, that's 120 entries. That's why I wanted to do it
generically using AllTypes.
Joni
On Mar 9, 12:07 pm, Belvasis <[email protected]> wrote:
But if you implement every repository based on the concrete type it
becomes
much easier:
<component
id="doc.repository"
service="Definition.IWriteRepository`1
[[Domain.Document,Domain]],
Definition"
type="DecoratorImpl.SecurityRepositoryDecorator`1
[[Domain.Document,Domain]],
DecoratorImpl"
lifestyle="transient">
<parameters>
<Inner>${doc.repository_impl}</Inner>
</parameters>
</component>
<component
id="doc.repository_Impl"
service="Definition.IWriteRepository`1
[[Domain.Document,Domain]],
Definition"
type="RepositoryImpl.DocumentRepository, RepositoryImpl"
lifestyle="transient">
</component>
So you can easily write
containter.Resolve<IWriteRepository<Document>>()
without needing a key. But maybe i miss something
from your requirements.
2010/3/9 Roelof Blom <[email protected]>
How would you ever guarantee the ordering of the decorators?
On Tue, Mar 9, 2010 at 10:50 AM, joniba <[email protected]> wrote:
I would also like to add that the scenario discussed on
http://stw.castleproject.org/Windsor.Decorators.ashx, as far as I
can
tell, does not support decorator chains, but only a single
decorator.
Because I could have a security-decorator that expects as its
inner a
transaction-decorator, whose inner would be the actual
implementation.
In which case the SelectHandler code, assuming the "inner" key
could
be passed to it, would still not be able to provide the desired
functionality.
Joni
On Mar 9, 11:32 am, joniba <[email protected]> wrote:
Hi Krzysztof,
Thanks for the links. Perhaps you can help me understand something
from the first one. Please bear with me as I am just getting
started
with Castle.
My question is about this method:
public IHandler SelectHandler(string key, Type service, IHandler[]
handlers)
{
if (!"inner".Equals(key,
StringComparison.OrdinalIgnoreCase))
{
return
handlers.Where(IsDecorator).FirstOrDefault();
}
return handlers.Where(h => IsDecorator(h) ==
false).FirstOrDefault();
}
First, in order for a key to be passed to the SelectHandler
method, I
would need to ask the container to resolve by key which, if I
understand correctly, it won't "just do" because my (in the
example)
CustomerRepositoryDecorator has a parameter named "inner" that
needs
to be resolved.
Hence, my conclusion is that registering the decorator would look
something like this:
container.Register
(
Component.For(typeof(IRepository<Customer>))
.ImplementedBy(typeof
(CustomerRepositoryDecorator))
.DynamicParameters
((kernel, dict) =>
dict["inner"] =
kernel.Resolve<IRepository<Customer>>("inner")
)
);
But of course that can't work because I have not registered any
component with key "inner". And I couldn't register the
CustomerRepository with key "inner" because there could be many
decorators or many repositories and the key must be unique.
Could you tell me what I'm missing?
Thanks
Joni
On Mar 8, 8:04 pm, Krzysztof Koźmic <[email protected]>
wrote:
http://stw.castleproject.org/Windsor.Decorators.ashxhttp://ayende.com
.
..
On 3/8/2010 6:47 PM, joniba wrote:
Hi Krzysztof, how would implementing the IHandlerSelector help
me?
How
will I differentiate between the initial call to (continuing the
example)
container.Resolve<IWriteRepository<Document>>()
With castle windsor's internal attempt to resolve the
SecurityRepositoryDecorator's "inner" parameter?
Thanks
Joni
On Mar 8, 7:17 pm, Krzysztof Koźmic<[email protected]>
wrote:
use IHandlerSelector
On 3/8/2010 5:59 PM, joniba wrote:
Hi all, I'm trying to use Castle Windsor to implement
decorator
chains, as per Ayende's msdn post. However, I'm using the
fluent
API,
and I want to know if it can be done en masse.
Without the decorators I have:
container.Register
(
AllTypes.FromAssembly(assembly)
.IncludeNonPublicTypes()
.BasedOn(typeof(IWriteRepository<>)).WithService.Base()
.Configure(component =>
component.LifeStyle.Transient)
);
(Which works fine.)
My decorators also implement IWriteRepository<T>, and take
as the
inner, an IWriteRepository<T>. For example:
public class SecurityRepositoryDecorator<TEntity> :
IWriteRepository<TEntity>
{
private IWriteRepository<TEntity> inner;
public
SecurityRepositoryDecorator(IWriteRepository<TEntity>
inner)
{
this.inner = inner;
}
}
Is this impossible because of a circular reference to
IWriteRepository<>?
I would like to get to:
var repository =
container.Resolve<IWriteRepository<Document>>();
And have this return a SecurityRepositoryDecorator wrapping a
DocumentRepository.
Any ideas are appreciated.
Joni
--
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
.
--
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.
