Suppose you have a linq to sql datacontext named MyDataContext that maps the tables for Customer and Order. The desired outcome is the following registrations IRepository<Customer> implemented by LinqRepository<Customer, MyDataContext> and IRepository<Order> implemented by LinqRepository<Order, MyDataContext>
On Mar 7, 8:05 pm, Krzysztof Koźmic <[email protected]> wrote: > What is U? > > How do *you *know which U is the right one? > > Is it like > > public class LinqRepo<Customer, CustomerU> :IRepository<Customer> {} > > is there some kind of convention like that? > > Krzysztof > > On 08/03/2011 1:36 AM, Rob wrote: > > > > > > > > > If someone asks for IRepo<T>, how would windsor know to return > > LinqRepo<T,U> ? > > > There has to be something that tells the container that entity type T > > comes from DataContext U. > > > On Mar 4, 6:08 pm, Krzysztof Koźmic<[email protected]> > > wrote: > >> Ah right, now I see. > > >> Why not just register IRepo<> and Linqrepo<,> as open generics, and > >> have them closed over A and B on demand as needed? > > >> On 05/03/2011 12:42 AM, Rob wrote: > > >>> That allows selection of multiple services for a single found type, > >>> but in my scenario, the found type (the datacontext) isn't actually > >>> the implementation type at all, it is merely the source for a list of > >>> components to be registered (irepo<a>, linqrepo<a, ctx>), (irepo<b>, > >>> linqrepo<b, ctx>), etc. > >>> On Mar 4, 8:23 am, Krzysztof Koźmic<[email protected]> > >>> wrote: > >>>> WithService.Select((a,b)=> bla) > >>>> On 05/03/2011 12:05 AM, Rob wrote: > >>>>> I think I must be missing it. FromAssemblyDescriptor and > >>>>> BasedOnDescriptor don't have a Select method on them. Plus, if Select > >>>>> is anything like the LINQ Select, it's map and therefore 1 to 1, where > >>>>> what I really need is SelectMany (1 to many mapping). > >>>>> On Mar 3, 5:17 pm, Krzysztof Koźmic<[email protected]> > >>>>> wrote: > >>>>>> There is, it's called Select > >>>>>> On 04/03/2011 8:33 AM, Rob wrote: > >>>>>>> I probably should have provided this detail up front. > >>>>>>> I have IRepository<TEntity> which is implemented by > >>>>>>> LinqRepository<TEntity, TDataContext>. > >>>>>>> So, for each type T in the assembly that inherits from DataContext I > >>>>>>> need to do: > >>>>>>> for each property of T whose type is Table<U>, register a > >>>>>>> component > >>>>>>> for IRepository<U> implemented by LinqRepository<U, T> > >>>>>>> The fact that I have to type all this out probably means that this is > >>>>>>> a special enough case not to be covered by the default API. It would > >>>>>>> be nice to have a general .SelectMany() hanging off the end of the > >>>>>>> type finding stuff so I could do something like: > >>>>>>> container.Register( > >>>>>>> AllTypes.FromThisAssembly() > >>>>>>> .BasedOn(....) > >>>>>>> .SelectMany(a single type => a set of Component > >>>>>>> registrations) > >>>>>>> ) > >>>>>>> On Mar 3, 3:20 pm, José F. Romaniello<[email protected]> > >>>>>>> wrote: > >>>>>>>> in the end you want to register > >>>>>>>> IRepository<T> pointing to Table<T>? > >>>>>>>> 2011/3/3 Rob<[email protected]> > >>>>>>>>> I'm using Windsor 2.5.3 and I'm trying to use the fluent > >>>>>>>>> registration > >>>>>>>>> API to register a set of components per type found. What I'm trying > >>>>>>>>> to > >>>>>>>>> achieve is roughly: > >>>>>>>>> for every type > >>>>>>>>> in this assembly > >>>>>>>>> that inherits from X > >>>>>>>>> don't register X, but instead use X to determine a set of > >>>>>>>>> components > >>>>>>>>> to register. > >>>>>>>>> The concrete example is that I want to find every DataContext in my > >>>>>>>>> assembly and rather than registering the DataContext itself, walk > >>>>>>>>> its > >>>>>>>>> properties and for each one that returns a Table<T>, register my own > >>>>>>>>> IRepository<T> as a component. > >>>>>>>>> I have a pretty strong suspicion that I'm just going to have to do > >>>>>>>>> this myself, but I would love to reuse the assembly walking code > >>>>>>>>> that > >>>>>>>>> Windsor clearly has. > >>>>>>>>> -- > >>>>>>>>> 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.
