It's hard for me to separate out and I don't have the rights to paste it directly.
The reflection is only necessary at container config time, thankfully. Are you aware of any other repository pattern implementation techniques for linq to sql? My goal is to avoid having to hand code a repository. Instead, we use a generic LinqRepo and base our abstractions around IQueryable<T>. So instead of encapsulating your query logic for Customers inside your hand coded CustomerRepository, my architecture gives you IRepository<Customer> : IQueryable<Customer> for free and then you make extension methods on IQueryable<Customer> to encapsulate your query logic. The basic moving pieces are: ISession (1 per mvc request, caches IUnitOfWork which is basically just DataContext or resolves new from the container on demand) Controllers take repos as ctor parameters and call IRepo.Enlist(ISession) with each one On Enlist, LinqRepo asks Session to GetUnitOfWork<TContext> All the IQueryable methods of LinqRepo just delegate to context.GetTable<TEntity>. Hopefully that's more clear rather than less. I've used this on projects before with great success, I was just looking for perhaps a cleaner way to get things initialized. For clients without IoC experience, one of the bigger stumbling points (regardless of all the other benefits) is weird looking 'magic' initialization code so I'm trying to simplify that as much as possible. On Mar 7, 10:33 am, José F. Romaniello <[email protected]> wrote: > would you mind to show LinqRepo<T,U> to see if i can help you? > I think the proceed you have described is overcomplicated and relfection > heavy but i might help you if i see the LinqRepo.. at least some methods > > thanks > > 2011/3/7 Rob <[email protected]> > > > > > > > > > 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. -- 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.
