Actually, thinking about 1. some more, I think it depends on your design as to whether any changes would be needed. Could you give me an example of how you hoped to use it? Mappings takes a lambda that gets applied to a MappingConfiguration instance, you can use multiple lambdas and they'll all get applied to the same instance. So if you had a class with a public method with a single MappingConfiguration parameter, that could be used in place of the lambda, making this quite easy to automate. Just thinking out loud. I'm curious to hear why the current design wouldn't work for you.
On Thu, Feb 19, 2009 at 12:42 PM, James Gregory <jagregory....@gmail.com>wrote: > Hi Martin, > 1. I'd not considered this usage, but it seems sensible. I'll make the > required changes so you can call Mappings multiple times. > > 2. This is difficult, because while the containers have the same purpose, > they don't have the same interface. Hbm and Fluent have some methods in > common (AddFromAssemblyOf<T>) but the automappings one has no common > methods. It's hard to extract a common interface from these. > > 3. Sounds good from a SoC point of view, but you might struggle merging the > various sources. FNH has several steps it goes through before it actually > touches the NH Configuration (notably conventions and some conflict > avoidance when using multiple mapping types). > > Personally, I'd go for the first approach once I fix the reuse issue. > > > On Thu, Feb 19, 2009 at 7:16 AM, Martin Nilsson <mffmar...@gmail.com>wrote: > >> I'm looking into replacing Castle ActiveRecord with FNH. I have an >> application built with modules and each module provide it's configuration >> for AR so I can get the AR entities. I don't know how to do that in FNH. I >> have considered these approaches. >> >> 1. Let each module provide a MappingConfiguration and then use add them to >> Fluently.Configure but if I do >> .Mappings(configOne) >> .Mappings(configTwo) >> etc >> it seems that the mapping is overwritten each time due to a delegate >> member >> >> 2. Add mappings to MappingConfiguration but it has three different >> properties (Fluent, Auto and Hbm with no relation (common interface)) so I >> have to know how the module has configured it's mappings. >> >> 3. Hmmm.. Now when I have done some thinking (or something..) I shouldn't >> get anything FNH related but a NH Configuration or NH mappings. It might be >> hard to merge the configuration from different sources so one option could >> be to give access to the _real_ configuration to the modules and then let >> them add their stuff to the configuration. So this post maybe should go into >> nhusers list instead.. >> >> Any ideas? >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to fluent-nhibernate@googlegroups.com To unsubscribe from this group, send email to fluent-nhibernate+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
