I think basically he wants automap built in, which we've already discussed.
So, I'd like to start a little discussion over how this would be implemented, I'm thinking something along the lines of:
var cfg = new Configuration() .Configure() .AutoMap(Assembly.LoadFrom("Name of assembly that contains your maps."));
or
var cfg = new Configuration() .Configure() .AutoMap("Namespace");
Ok, so thinking from here, I think the rest is quite straight forward. I'm thinking something along the lines of:
- if the property has a setter then it's stored in nhibernate and is mapped. - If it contains a collection then it's mapped as many-to-one - If the class is inherits from a mapped type then it's a subclass
Now the sticking point, many-to-many joins? Any idea's?
I dislike the use of extension methods on the NHibernate Configuration. We have a PersistenceModel which deals with all our setup and conventions, so I think the automap should be baked into that.
> - if the property has a setter then it's stored in nhibernate and is > mapped. > - If it contains a collection then it's mapped as many-to-one > - If the class is inherits from a mapped type then it's a subclass
> This all needs to be done through our convention API, and we can discuss
what needs to go into the DefaultConvention.
I agree that we need to have a discussion about this. I'm in the process of evaluating what our convention support is like, and where we need to improve on it.
On Wed, Aug 13, 2008 at 11:14 AM, Andrew Stewart <
> I think basically he wants automap built in, which we've already discussed.
> So, I'd like to start a little discussion over how this would be > implemented, I'm thinking something along the lines of:
> var cfg = new Configuration() > .Configure() > .AutoMap(Assembly.LoadFrom("Name of assembly that contains > your maps."));
> or
> var cfg = new Configuration() > .Configure() > .AutoMap("Namespace");
> Ok, so thinking from here, I think the rest is quite straight forward. I'm > thinking something along the lines of:
> - if the property has a setter then it's stored in nhibernate and is > mapped. > - If it contains a collection then it's mapped as many-to-one > - If the class is inherits from a mapped type then it's a subclass
> Now the sticking point, many-to-many joins? Any idea's?
> I dislike the use of extension methods on the NHibernate Configuration.
I actually disagree with this, as I think from a user coming to use the project then you want to make using the library as simple as possible. So links from the nhibernate configuration seems a natural place to put them. However your right in that the actual implementation should live in the PersistanceModel, as this is the correct SoC.
In my opinion I'd of thought the convention would be about naming conventions and defaults, rather than how you analyse the assmebly - suppose it depends on your definition though.
Anyway I'd just thought I'd start a discussion as to how we define these, as I'm quite keen to look into it.
Cheers
Andy
On Wed, Aug 13, 2008 at 11:20 AM, James Gregory <jagregory....@gmail.com>wrote:
> I dislike the use of extension methods on the NHibernate Configuration. We > have a PersistenceModel which deals with all our setup and conventions, so I > think the automap should be baked into that.
>> - if the property has a setter then it's stored in nhibernate and is >> mapped. >> - If it contains a collection then it's mapped as many-to-one >> - If the class is inherits from a mapped type then it's a subclass
>> This all needs to be done through our convention API, and we can discuss > what needs to go into the DefaultConvention.
> I agree that we need to have a discussion about this. I'm in the process of > evaluating what our convention support is like, and where we need to improve > on it.
> On Wed, Aug 13, 2008 at 11:14 AM, Andrew Stewart < > andrew.stew...@i-nnovate.net> wrote:
>> I think basically he wants automap built in, which we've already >> discussed.
>> So, I'd like to start a little discussion over how this would be >> implemented, I'm thinking something along the lines of:
>> var cfg = new Configuration() >> .Configure() >> .AutoMap(Assembly.LoadFrom("Name of assembly that >> contains your maps."));
>> or
>> var cfg = new Configuration() >> .Configure() >> .AutoMap("Namespace");
>> Ok, so thinking from here, I think the rest is quite straight forward. I'm >> thinking something along the lines of:
>> - if the property has a setter then it's stored in nhibernate and is >> mapped. >> - If it contains a collection then it's mapped as many-to-one >> - If the class is inherits from a mapped type then it's a subclass
>> Now the sticking point, many-to-many joins? Any idea's?
> In my opinion I'd of thought the convention would be about naming > conventions and defaults, rather than how you analyse the assmebly - suppose > it depends on your definition though.
Conventions currently are about naming and defaults, but they're also about types. So if we iterate through the types in an assembly, then run them through the conventions, we should be able to produce a mapping from them.
Anyway I'd just thought I'd start a discussion as to how we define these, as
> I'm quite keen to look into it.
I agree we need to discuss these ideas, but I'm not interested in knee-jerk reacting to this. We need to get our API implemented properly before we're even able to tackle this, there's no point implementing auto-mapping when we don't even fully support the normal mappings.
By all means though, discuss away. We need to decide how we're to approach this.
On Wed, Aug 13, 2008 at 11:34 AM, Andrew Stewart <
>> I dislike the use of extension methods on the NHibernate Configuration.
> I actually disagree with this, as I think from a user coming to use the > project then you want to make using the library as simple as possible. So > links from the nhibernate configuration seems a natural place to put them. > However your right in that the actual implementation should live in the > PersistanceModel, as this is the correct SoC.
> In my opinion I'd of thought the convention would be about naming > conventions and defaults, rather than how you analyse the assmebly - suppose > it depends on your definition though.
> Anyway I'd just thought I'd start a discussion as to how we define these, > as I'm quite keen to look into it.
> Cheers
> Andy
> On Wed, Aug 13, 2008 at 11:20 AM, James Gregory <jagregory....@gmail.com>wrote:
>> I dislike the use of extension methods on the NHibernate Configuration. We >> have a PersistenceModel which deals with all our setup and conventions, so I >> think the automap should be baked into that.
>>> - if the property has a setter then it's stored in nhibernate and is >>> mapped. >>> - If it contains a collection then it's mapped as many-to-one >>> - If the class is inherits from a mapped type then it's a subclass
>>> This all needs to be done through our convention API, and we can discuss >> what needs to go into the DefaultConvention.
>> I agree that we need to have a discussion about this. I'm in the process >> of evaluating what our convention support is like, and where we need to >> improve on it.
>> On Wed, Aug 13, 2008 at 11:14 AM, Andrew Stewart < >> andrew.stew...@i-nnovate.net> wrote:
>>> I think basically he wants automap built in, which we've already >>> discussed.
>>> So, I'd like to start a little discussion over how this would be >>> implemented, I'm thinking something along the lines of:
>>> var cfg = new Configuration() >>> .Configure() >>> .AutoMap(Assembly.LoadFrom("Name of assembly that >>> contains your maps."));
>>> or
>>> var cfg = new Configuration() >>> .Configure() >>> .AutoMap("Namespace");
>>> Ok, so thinking from here, I think the rest is quite straight forward. >>> I'm thinking something along the lines of:
>>> - if the property has a setter then it's stored in nhibernate and is >>> mapped. >>> - If it contains a collection then it's mapped as many-to-one >>> - If the class is inherits from a mapped type then it's a subclass
>>> Now the sticking point, many-to-many joins? Any idea's?
> I agree we need to discuss these ideas, but I'm not interested in knee-jerk > reacting to this. We need to get our API implemented properly before we're > even able to tackle this, there's no point implementing auto-mapping when we > don't even fully support the normal mappings.
Yeah I agree, it shouldn't be knee jerk but I do think we have enough implemented to do it. After all I don't think that automapping could do the advanced situation's and all the basic's are already implemented.
Your right though we need to look into getting the convention part polished all the same. As it would be nice to provide your own conventions which I don't think you can at the moment(haven't looked).
I've been playing round with this since I sent the first email, and 235 lines of code later(including tests). I've managed to write a layer that sit's over fluentnHibernate. That supports AutoMapping the following parts of your object:
new AutoMapIdentity(), new AutoMapVersion(), new AutoMapProperty(), new AutoMapManyToOne(), new AutoMapOneToMany(), My next step is to get inheritance working, which seems straight forward enough, however I'm still struggling to think of a decent way to make many-to-many joins and one-to-one.
Anyone got any idea's, on naming conventions or anything similar.
Cheers
Andy
On Wed, Aug 13, 2008 at 11:46 AM, Andrew Stewart <
andrew.stew...@i-nnovate.net> wrote: > I agree we need to discuss these ideas, but I'm not interested in >> knee-jerk reacting to this. We need to get our API implemented properly >> before we're even able to tackle this, there's no point implementing >> auto-mapping when we don't even fully support the normal mappings.
> Yeah I agree, it shouldn't be knee jerk but I do think we have enough > implemented to do it. After all I don't think that automapping could do the > advanced situation's and all the basic's are already implemented.
> Your right though we need to look into getting the convention part polished > all the same. As it would be nice to provide your own conventions which I > don't think you can at the moment(haven't looked).
We've already got the baseline convention stuff for properties and attributes, so just let the automap reflect over the properties and add the mapping parts to the ClassMap. The same convention code should take over from there.
It might be worthwhile to start extending the Conventions class independently of the automap.
Another thing to think of is using the automapping on a class by class basis, but then letting the ClassMap override one or more properties.
I'd vote for avoiding many to many in the automapping. I think that's where the automapping becomes more of a problem than a solution.
Jeremy D. Miller The Shade Tree Developer jeremydmil...@yahoo.com
----- Original Message ---- From: Andrew Stewart <andrew.stew...@i-nnovate.net> To: fluent-nhibernate@googlegroups.com Sent: Wednesday, August 13, 2008 10:08:03 AM Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
Ok
I've been playing round with this since I sent the first email, and 235 lines of code later(including tests). I've managed to write a layer that sit's over fluentnHibernate. That supports AutoMapping the following parts of your object: new AutoMapIdentity(), new AutoMapVersion(), new AutoMapProperty(), new AutoMapManyToOne(), new AutoMapOneToMany(), My next step is to get inheritance working, which seems straight forward enough, however I'm still struggling to think of a decent way to make many-to-many joins and one-to-one.
Anyone got any idea's, on naming conventions or anything similar.
Cheers
Andy
On Wed, Aug 13, 2008 at 11:46 AM, Andrew Stewart <andrew.stew...@i-nnovate.net> wrote:
I agree we need to discuss these ideas, but I'm not interested in knee-jerk reacting to this. We need to get our API implemented properly before we're even able to tackle this, there's no point implementing auto-mapping when we don't even fully support the normal mappings.
Yeah I agree, it shouldn't be knee jerk but I do think we have enough implemented to do it. After all I don't think that automapping could do the advanced situation's and all the basic's are already implemented.
Your right though we need to look into getting the convention part polished all the same. As it would be nice to provide your own conventions which I don't think you can at the moment(haven't looked).
Thats pretty much how it does work. My automap just sits above the fluentnHibernate library and call's the exact same methods a user would, (which wasn't easy to figure out creating expressions at runtime). It just needs to hand off some responsibilities to the convention class to decide if the Id is the Indentifier or if the Version Property is the versioning attribute is etc. I can commit as a seperate project over fluentnhibernnate say fluentnhibernnate.AutoMapper or add it to the framework project if people would find it interesting.
The way I'm using at the moment is pretty much as you describe something close to
model .AutoMap<Address>() .AutoMap<Company>() .AutoMap<Contact>()
Then you can load in the rest of the maps the same way as you normally do.
Cheers
Andy
On Wed, Aug 13, 2008 at 4:11 PM, Jeremy D. Miller <jeremydmil...@yahoo.com>wrote:
> We've already got the baseline convention stuff for properties and > attributes, so just let the automap reflect over the properties and add the > mapping parts to the ClassMap. The same convention code should take over > from there.
> It might be worthwhile to start extending the Conventions class > independently of the automap.
> Another thing to think of is using the automapping on a class by class > basis, but then letting the ClassMap override one or more properties.
> I'd vote for avoiding many to many in the automapping. I think that's > where the automapping becomes more of a problem than a solution.
> ----- Original Message ---- > From: Andrew Stewart <andrew.stew...@i-nnovate.net> > To: fluent-nhibernate@googlegroups.com > Sent: Wednesday, August 13, 2008 10:08:03 AM > Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
> Ok
> I've been playing round with this since I sent the first email, and 235 > lines of code later(including tests). I've managed to write a layer that > sit's over fluentnHibernate. That supports AutoMapping the following parts > of your object:
> new AutoMapIdentity(), > new AutoMapVersion(), > new AutoMapProperty(), > new AutoMapManyToOne(), > new AutoMapOneToMany(),
> My next step is to get inheritance working, which seems straight forward > enough, however I'm still struggling to think of a decent way to make > many-to-many joins and one-to-one.
> Anyone got any idea's, on naming conventions or anything similar.
> Cheers
> Andy
> On Wed, Aug 13, 2008 at 11:46 AM, Andrew Stewart < > andrew.stew...@i-nnovate.net> wrote:
>> I agree we need to discuss these ideas, but I'm not interested in >>> knee-jerk reacting to this. We need to get our API implemented properly >>> before we're even able to tackle this, there's no point implementing >>> auto-mapping when we don't even fully support the normal mappings.
>> Yeah I agree, it shouldn't be knee jerk but I do think we have enough >> implemented to do it. After all I don't think that automapping could do the >> advanced situation's and all the basic's are already implemented.
>> Your right though we need to look into getting the convention part >> polished all the same. As it would be nice to provide your own conventions >> which I don't think you can at the moment(haven't looked).
> Thats pretty much how it does work. My automap just sits above the > fluentnHibernate library and call's the exact same methods a user would, > (which wasn't easy to figure out creating expressions at runtime). It just > needs to hand off some responsibilities to the convention class to decide if > the Id is the Indentifier or if the Version Property is the versioning > attribute is etc. I can commit as a seperate project over fluentnhibernnate > say fluentnhibernnate.AutoMapper or add it to the framework project if > people would find it interesting.
> The way I'm using at the moment is pretty much as you describe something > close to
> model > .AutoMap<Address>() > .AutoMap<Company>() > .AutoMap<Contact>()
> Then you can load in the rest of the maps the same way as you normally do.
> Cheers
> Andy
> On Wed, Aug 13, 2008 at 4:11 PM, Jeremy D. Miller <jeremydmil...@yahoo.com > > wrote:
>> We've already got the baseline convention stuff for properties and >> attributes, so just let the automap reflect over the properties and add the >> mapping parts to the ClassMap. The same convention code should take over >> from there.
>> It might be worthwhile to start extending the Conventions class >> independently of the automap.
>> Another thing to think of is using the automapping on a class by class >> basis, but then letting the ClassMap override one or more properties.
>> I'd vote for avoiding many to many in the automapping. I think that's >> where the automapping becomes more of a problem than a solution.
>> ----- Original Message ---- >> From: Andrew Stewart <andrew.stew...@i-nnovate.net> >> To: fluent-nhibernate@googlegroups.com >> Sent: Wednesday, August 13, 2008 10:08:03 AM >> Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
>> Ok
>> I've been playing round with this since I sent the first email, and 235 >> lines of code later(including tests). I've managed to write a layer that >> sit's over fluentnHibernate. That supports AutoMapping the following parts >> of your object:
>> new AutoMapIdentity(), >> new AutoMapVersion(), >> new AutoMapProperty(), >> new AutoMapManyToOne(), >> new AutoMapOneToMany(),
>> My next step is to get inheritance working, which seems straight forward >> enough, however I'm still struggling to think of a decent way to make >> many-to-many joins and one-to-one.
>> Anyone got any idea's, on naming conventions or anything similar.
>> Cheers
>> Andy
>> On Wed, Aug 13, 2008 at 11:46 AM, Andrew Stewart < >> andrew.stew...@i-nnovate.net> wrote:
>>> I agree we need to discuss these ideas, but I'm not interested in >>>> knee-jerk reacting to this. We need to get our API implemented properly >>>> before we're even able to tackle this, there's no point implementing >>>> auto-mapping when we don't even fully support the normal mappings.
>>> Yeah I agree, it shouldn't be knee jerk but I do think we have enough >>> implemented to do it. After all I don't think that automapping could do the >>> advanced situation's and all the basic's are already implemented.
>>> Your right though we need to look into getting the convention part >>> polished all the same. As it would be nice to provide your own conventions >>> which I don't think you can at the moment(haven't looked).
On Wed, Aug 13, 2008 at 8:21 PM, Kyle Baley <k...@baley.org> wrote: > Well, what're you waiting for? Check it in, man!
> On Wed, Aug 13, 2008 at 12:35 PM, Andrew Stewart < > andrew.stew...@i-nnovate.net> wrote:
>> Hi Jeremy
>> Thats pretty much how it does work. My automap just sits above the >> fluentnHibernate library and call's the exact same methods a user would, >> (which wasn't easy to figure out creating expressions at runtime). It just >> needs to hand off some responsibilities to the convention class to decide if >> the Id is the Indentifier or if the Version Property is the versioning >> attribute is etc. I can commit as a seperate project over fluentnhibernnate >> say fluentnhibernnate.AutoMapper or add it to the framework project if >> people would find it interesting.
>> The way I'm using at the moment is pretty much as you describe something >> close to
>> model >> .AutoMap<Address>() >> .AutoMap<Company>() >> .AutoMap<Contact>()
>> Then you can load in the rest of the maps the same way as you normally do.
>> Cheers
>> Andy
>> On Wed, Aug 13, 2008 at 4:11 PM, Jeremy D. Miller < >> jeremydmil...@yahoo.com> wrote:
>>> We've already got the baseline convention stuff for properties and >>> attributes, so just let the automap reflect over the properties and add the >>> mapping parts to the ClassMap. The same convention code should take over >>> from there.
>>> It might be worthwhile to start extending the Conventions class >>> independently of the automap.
>>> Another thing to think of is using the automapping on a class by class >>> basis, but then letting the ClassMap override one or more properties.
>>> I'd vote for avoiding many to many in the automapping. I think that's >>> where the automapping becomes more of a problem than a solution.
>>> ----- Original Message ---- >>> From: Andrew Stewart <andrew.stew...@i-nnovate.net> >>> To: fluent-nhibernate@googlegroups.com >>> Sent: Wednesday, August 13, 2008 10:08:03 AM >>> Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
>>> Ok
>>> I've been playing round with this since I sent the first email, and 235 >>> lines of code later(including tests). I've managed to write a layer that >>> sit's over fluentnHibernate. That supports AutoMapping the following parts >>> of your object:
>>> new AutoMapIdentity(), >>> new AutoMapVersion(), >>> new AutoMapProperty(), >>> new AutoMapManyToOne(), >>> new AutoMapOneToMany(),
>>> My next step is to get inheritance working, which seems straight forward >>> enough, however I'm still struggling to think of a decent way to make >>> many-to-many joins and one-to-one.
>>> Anyone got any idea's, on naming conventions or anything similar.
>>> Cheers
>>> Andy
>>> On Wed, Aug 13, 2008 at 11:46 AM, Andrew Stewart < >>> andrew.stew...@i-nnovate.net> wrote:
>>>> I agree we need to discuss these ideas, but I'm not interested in >>>>> knee-jerk reacting to this. We need to get our API implemented properly >>>>> before we're even able to tackle this, there's no point implementing >>>>> auto-mapping when we don't even fully support the normal mappings.
>>>> Yeah I agree, it shouldn't be knee jerk but I do think we have enough >>>> implemented to do it. After all I don't think that automapping could do the >>>> advanced situation's and all the basic's are already implemented.
>>>> Your right though we need to look into getting the convention part >>>> polished all the same. As it would be nice to provide your own conventions >>>> which I don't think you can at the moment(haven't looked).
One thing I'm not sure about yet is the separation between regular mapping and auto-mapping. I've been wrestling with the idea of auto-mapping being the default, and explicit mapping be only for exceptional circumstances.
var model = new ExplicitMappedPersistenceModel(); model.AddMappingAssembly(asm);
That would interrogate assemblies for any types derived from ExplicitClassMap (currently ClassMap), and run as we've currently got it setup.
var model = new AutoMappedPersistenceModel(); model.AddMappingAssembly(asm, type => type.Namespace == "Product.Mapping");
However, the above example would auto-map all types found in the assembly (that match the expression), then also find any types of ExtendedClassMap and update any auto-maps with overrides from these types.
Thoughts?
Andrew: Nice work! By all means commit your stuff, I'm purely speculating here.
andrew.stew...@i-nnovate.net> wrote: > Doh, left it on the machine at work. Doh Doh Doh! It'll be in first thing > in the morning, GMT that is.
> On Wed, Aug 13, 2008 at 8:21 PM, Kyle Baley <k...@baley.org> wrote:
>> Well, what're you waiting for? Check it in, man!
>> On Wed, Aug 13, 2008 at 12:35 PM, Andrew Stewart < >> andrew.stew...@i-nnovate.net> wrote:
>>> Hi Jeremy
>>> Thats pretty much how it does work. My automap just sits above the >>> fluentnHibernate library and call's the exact same methods a user would, >>> (which wasn't easy to figure out creating expressions at runtime). It just >>> needs to hand off some responsibilities to the convention class to decide if >>> the Id is the Indentifier or if the Version Property is the versioning >>> attribute is etc. I can commit as a seperate project over fluentnhibernnate >>> say fluentnhibernnate.AutoMapper or add it to the framework project if >>> people would find it interesting.
>>> The way I'm using at the moment is pretty much as you describe something >>> close to
>>> model >>> .AutoMap<Address>() >>> .AutoMap<Company>() >>> .AutoMap<Contact>()
>>> Then you can load in the rest of the maps the same way as you normally >>> do.
>>> Cheers
>>> Andy
>>> On Wed, Aug 13, 2008 at 4:11 PM, Jeremy D. Miller < >>> jeremydmil...@yahoo.com> wrote:
>>>> We've already got the baseline convention stuff for properties and >>>> attributes, so just let the automap reflect over the properties and add the >>>> mapping parts to the ClassMap. The same convention code should take over >>>> from there.
>>>> It might be worthwhile to start extending the Conventions class >>>> independently of the automap.
>>>> Another thing to think of is using the automapping on a class by class >>>> basis, but then letting the ClassMap override one or more properties.
>>>> I'd vote for avoiding many to many in the automapping. I think that's >>>> where the automapping becomes more of a problem than a solution.
>>>> ----- Original Message ---- >>>> From: Andrew Stewart <andrew.stew...@i-nnovate.net> >>>> To: fluent-nhibernate@googlegroups.com >>>> Sent: Wednesday, August 13, 2008 10:08:03 AM >>>> Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
>>>> Ok
>>>> I've been playing round with this since I sent the first email, and 235 >>>> lines of code later(including tests). I've managed to write a layer that >>>> sit's over fluentnHibernate. That supports AutoMapping the following parts >>>> of your object:
>>>> new AutoMapIdentity(), >>>> new AutoMapVersion(), >>>> new AutoMapProperty(), >>>> new AutoMapManyToOne(), >>>> new AutoMapOneToMany(),
>>>> My next step is to get inheritance working, which seems straight forward >>>> enough, however I'm still struggling to think of a decent way to make >>>> many-to-many joins and one-to-one.
>>>> Anyone got any idea's, on naming conventions or anything similar.
>>>> Cheers
>>>> Andy
>>>> On Wed, Aug 13, 2008 at 11:46 AM, Andrew Stewart < >>>> andrew.stew...@i-nnovate.net> wrote:
>>>>> I agree we need to discuss these ideas, but I'm not interested in >>>>>> knee-jerk reacting to this. We need to get our API implemented properly >>>>>> before we're even able to tackle this, there's no point implementing >>>>>> auto-mapping when we don't even fully support the normal mappings.
>>>>> Yeah I agree, it shouldn't be knee jerk but I do think we have enough >>>>> implemented to do it. After all I don't think that automapping could do the >>>>> advanced situation's and all the basic's are already implemented.
>>>>> Your right though we need to look into getting the convention part >>>>> polished all the same. As it would be nice to provide your own conventions >>>>> which I don't think you can at the moment(haven't looked).
From what I've seen I can do do 80% of my classes with automap, and only had to override for Many-To-Many and inheritance although I think I can get inheritance working I just havent *yet*.
This is how it works at the moment
var model = new AutoPersistanceModel(); model.AutoMap<Address>() .AutoMap<Company>() .AutoMap<Contact>()
Now I quite like the look of what your suggesting, however when I asked a collegue he suggested he liked seeing exactly what was mapped and what wasn't(not sure I agree with him - but something to chew over)
var model = new AutoMappedPersistenceModel(). model.AddMappingAssembly(asm, type => type.Namespace == "Product.Mapping") .Exclude<Address>();
Or as you say find all classMaps first and ignore those types, it doesnt do it at the mo but as I havent wrote those bits on mapping entire assemblies, *yet*.
Oh and I just checked in the AutoMapper
Cheers
Andy
On Wed, Aug 13, 2008 at 8:32 PM, James Gregory <jagregory....@gmail.com>wrote:
> One thing I'm not sure about yet is the separation between regular > mapping and auto-mapping. I've been wrestling with the idea of auto-mapping > being the default, and explicit mapping be only for exceptional > circumstances.
> var model = new ExplicitMappedPersistenceModel(); > model.AddMappingAssembly(asm);
> That would interrogate assemblies for any types derived from > ExplicitClassMap (currently ClassMap), and run as we've currently got it > setup.
> var model = new AutoMappedPersistenceModel(); > model.AddMappingAssembly(asm, type => type.Namespace == "Product.Mapping");
> However, the above example would auto-map all types found in the assembly > (that match the expression), then also find any types of ExtendedClassMap > and update any auto-maps with overrides from these types.
> Thoughts?
> Andrew: Nice work! By all means commit your stuff, I'm purely speculating > here.
> On Wed, Aug 13, 2008 at 8:23 PM, Andrew Stewart < > andrew.stew...@i-nnovate.net> wrote:
>> Doh, left it on the machine at work. Doh Doh Doh! It'll be in first >> thing in the morning, GMT that is.
>> On Wed, Aug 13, 2008 at 8:21 PM, Kyle Baley <k...@baley.org> wrote:
>>> Well, what're you waiting for? Check it in, man!
>>> On Wed, Aug 13, 2008 at 12:35 PM, Andrew Stewart < >>> andrew.stew...@i-nnovate.net> wrote:
>>>> Hi Jeremy
>>>> Thats pretty much how it does work. My automap just sits above the >>>> fluentnHibernate library and call's the exact same methods a user would, >>>> (which wasn't easy to figure out creating expressions at runtime). It just >>>> needs to hand off some responsibilities to the convention class to decide if >>>> the Id is the Indentifier or if the Version Property is the versioning >>>> attribute is etc. I can commit as a seperate project over fluentnhibernnate >>>> say fluentnhibernnate.AutoMapper or add it to the framework project if >>>> people would find it interesting.
>>>> The way I'm using at the moment is pretty much as you describe something >>>> close to
>>>> model >>>> .AutoMap<Address>() >>>> .AutoMap<Company>() >>>> .AutoMap<Contact>()
>>>> Then you can load in the rest of the maps the same way as you normally >>>> do.
>>>> Cheers
>>>> Andy
>>>> On Wed, Aug 13, 2008 at 4:11 PM, Jeremy D. Miller < >>>> jeremydmil...@yahoo.com> wrote:
>>>>> We've already got the baseline convention stuff for properties and >>>>> attributes, so just let the automap reflect over the properties and add the >>>>> mapping parts to the ClassMap. The same convention code should take over >>>>> from there.
>>>>> It might be worthwhile to start extending the Conventions class >>>>> independently of the automap.
>>>>> Another thing to think of is using the automapping on a class by class >>>>> basis, but then letting the ClassMap override one or more properties.
>>>>> I'd vote for avoiding many to many in the automapping. I think that's >>>>> where the automapping becomes more of a problem than a solution.
>>>>> ----- Original Message ---- >>>>> From: Andrew Stewart <andrew.stew...@i-nnovate.net> >>>>> To: fluent-nhibernate@googlegroups.com >>>>> Sent: Wednesday, August 13, 2008 10:08:03 AM >>>>> Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
>>>>> Ok
>>>>> I've been playing round with this since I sent the first email, and 235 >>>>> lines of code later(including tests). I've managed to write a layer that >>>>> sit's over fluentnHibernate. That supports AutoMapping the following parts >>>>> of your object:
>>>>> new AutoMapIdentity(), >>>>> new AutoMapVersion(), >>>>> new AutoMapProperty(), >>>>> new AutoMapManyToOne(), >>>>> new AutoMapOneToMany(),
>>>>> My next step is to get inheritance working, which seems straight >>>>> forward enough, however I'm still struggling to think of a decent way to >>>>> make many-to-many joins and one-to-one.
>>>>> Anyone got any idea's, on naming conventions or anything similar.
>>>>> Cheers
>>>>> Andy
>>>>> On Wed, Aug 13, 2008 at 11:46 AM, Andrew Stewart < >>>>> andrew.stew...@i-nnovate.net> wrote:
>>>>>> I agree we need to discuss these ideas, but I'm not interested in >>>>>>> knee-jerk reacting to this. We need to get our API implemented properly >>>>>>> before we're even able to tackle this, there's no point implementing >>>>>>> auto-mapping when we don't even fully support the normal mappings.
>>>>>> Yeah I agree, it shouldn't be knee jerk but I do think we have enough >>>>>> implemented to do it. After all I don't think that automapping could do the >>>>>> advanced situation's and all the basic's are already implemented.
>>>>>> Your right though we need to look into getting the convention part >>>>>> polished all the same. As it would be nice to provide your own conventions >>>>>> which I don't think you can at the moment(haven't looked).
> var autoModel = new AutoPersistenceModel(Assembly.GetAssembly(typeof( > AutoMapTests))); > autoModel.AddEntityAssembly(Assembly.GetAssembly(typeof (AutoMapTests)),t > => t.Namespace == "FluentNHibernate.AutoMap.Test");
Now that should add the ability to maps load all maps that are manually created, plus automap the other objects. Now here comes the problem I have at the moment, I have no easy way to tell what properties have been manually mapped, so that I can ignore them when automapping. Does anyone know of any easy way to find this out?
I was looking at the code, and I'm really not crazy about the "findMappings" business. that's really smelly. What was the intention here? I'm hoping we can find a better way of doing that. It feels like cheating to use string-based reflection in a project who's main intention is to solely use static reflection, haha!!!
When I think of Automapping, here's what I'm thinking:
var model = AutoPersistenceModel
.MapEntitiesFromAssemblyOf<AutoMapTests>()
.Where(t => t.Namespace == "FluentNHibernate.AutoMap.Test")
.ForTypesThatDeriveFrom<DomainEntity>(map =>
{
map.UseIdentityForKey(e => e.Id, "Id");
});
As far as dupe properties, I would expect that people would do AutoMap first, then provide explicit overrides. So the persistence model would have to be smart enough to know that a type was already mapped so when you map a property, it grabs the existing mapped property and merges the changes there.
Thoughts?
Chad
________________________________
From: fluent-nhibernate@googlegroups.com on behalf of Andrew Stewart
Sent: Thu 8/14/2008 3:39 PM
To: fluent-nhibernate@googlegroups.com
Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
Just committed this experimental metthod:
var autoModel = new AutoPersistenceModel(Assembly.GetAssembly(typeof(AutoMapTests)));
autoModel.AddEntityAssembly(Assembly.GetAssembly(typeof (AutoMapTests)),t => t.Namespace == "FluentNHibernate.AutoMap.Test");
Now that should add the ability to maps load all maps that are manually created, plus automap the other objects. Now here comes the problem I have at the moment, I have no easy way to tell what properties have been manually mapped, so that I can ignore them when automapping. Does anyone know of any easy way to find this out?
On Fri, Aug 15, 2008 at 12:24 AM, Chad Myers <c...@chadmyers.com> wrote: > Andrew,
> Thanks for doing this. Cool stuff!
> I was looking at the code, and I'm really not crazy about the > "findMappings" business. that's really smelly. What was the intention here? > I'm hoping we can find a better way of doing that. It feels like cheating to > use string-based reflection in a project who's main intention is to solely > use static reflection, haha!!!
> When I think of Automapping, here's what I'm thinking:
> var model = AutoPersistenceModel > .MapEntitiesFromAssemblyOf<AutoMapTests>() > .Where(t => t.Namespace == "FluentNHibernate.AutoMap.Test") > .ForTypesThatDeriveFrom<DomainEntity>(map => > {
> map.UseIdentityForKey(e => e.Id, "Id"); > });
> As far as dupe properties, I would expect that people would do AutoMap > first, then provide explicit overrides. So the persistence model would have > to be smart enough to know that a type was already mapped so when you map a > property, it grabs the existing mapped property and merges the changes > there.
> Thoughts?
> Chad
> ________________________________
> From: fluent-nhibernate@googlegroups.com on behalf of Andrew Stewart > Sent: Thu 8/14/2008 3:39 PM > To: fluent-nhibernate@googlegroups.com > Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
> Just committed this experimental metthod:
> var autoModel = new > AutoPersistenceModel(Assembly.GetAssembly(typeof(AutoMapTests))); > autoModel.AddEntityAssembly(Assembly.GetAssembly(typeof > (AutoMapTests)),t => t.Namespace == "FluentNHibernate.AutoMap.Test");
> Now that should add the ability to maps load all maps that are manually > created, plus automap the other objects. Now here comes the problem I have > at the moment, I have no easy way to tell what properties have been manually > mapped, so that I can ignore them when automapping. Does anyone know of any > easy way to find this out?
> this seems very reasonable to me. Automatically provide the defaults and > then MERGE in the user specific mappings.
> On Fri, Aug 15, 2008 at 12:24 AM, Chad Myers <c...@chadmyers.com> wrote:
>> Andrew,
>> Thanks for doing this. Cool stuff!
>> I was looking at the code, and I'm really not crazy about the >> "findMappings" business. that's really smelly. What was the intention here? >> I'm hoping we can find a better way of doing that. It feels like cheating to >> use string-based reflection in a project who's main intention is to solely >> use static reflection, haha!!!
>> When I think of Automapping, here's what I'm thinking:
>> var model = AutoPersistenceModel >> .MapEntitiesFromAssemblyOf<AutoMapTests>() >> .Where(t => t.Namespace == "FluentNHibernate.AutoMap.Test") >> .ForTypesThatDeriveFrom<DomainEntity>(map => >> {
>> map.UseIdentityForKey(e => e.Id, "Id"); >> });
>> As far as dupe properties, I would expect that people would do AutoMap >> first, then provide explicit overrides. So the persistence model would have >> to be smart enough to know that a type was already mapped so when you map a >> property, it grabs the existing mapped property and merges the changes >> there.
>> Thoughts?
>> Chad
>> ________________________________
>> From: fluent-nhibernate@googlegroups.com on behalf of Andrew Stewart >> Sent: Thu 8/14/2008 3:39 PM >> To: fluent-nhibernate@googlegroups.com >> Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
>> Just committed this experimental metthod:
>> var autoModel = new >> AutoPersistenceModel(Assembly.GetAssembly(typeof(AutoMapTests))); >> autoModel.AddEntityAssembly(Assembly.GetAssembly(typeof >> (AutoMapTests)),t => t.Namespace == "FluentNHibernate.AutoMap.Test");
>> Now that should add the ability to maps load all maps that are manually >> created, plus automap the other objects. Now here comes the problem I have >> at the moment, I have no easy way to tell what properties have been manually >> mapped, so that I can ignore them when automapping. Does anyone know of any >> easy way to find this out?
var mapping = executeMethod(obj, this, "findMapping", null);
if (mapping != null) { executeMethod(obj, autoMap, "Map", new[] {mapping});
}
else { executeMethod(obj, autoMap, "Map", null);
}
Your right it does smell a tad, here's the problem, I need to execute a generic method either on the base class or on the automapper. However I don't know the type, as it's defined at runtime and this is the only way I could get it to work.
Now if anyone know's a way of calling these generic methods statically typed, I'll send them a big virtual hug as this has break me on refactoring written all over it.
On Thu, Aug 14, 2008 at 11:24 PM, Chad Myers <c...@chadmyers.com> wrote: > Andrew,
> Thanks for doing this. Cool stuff!
> I was looking at the code, and I'm really not crazy about the > "findMappings" business. that's really smelly. What was the intention here? > I'm hoping we can find a better way of doing that. It feels like cheating to > use string-based reflection in a project who's main intention is to solely > use static reflection, haha!!!
> When I think of Automapping, here's what I'm thinking:
> var model = AutoPersistenceModel > .MapEntitiesFromAssemblyOf<AutoMapTests>() > .Where(t => t.Namespace == "FluentNHibernate.AutoMap.Test") > .ForTypesThatDeriveFrom<DomainEntity>(map => > {
> map.UseIdentityForKey(e => e.Id, "Id"); > });
> As far as dupe properties, I would expect that people would do AutoMap > first, then provide explicit overrides. So the persistence model would have > to be smart enough to know that a type was already mapped so when you map a > property, it grabs the existing mapped property and merges the changes > there.
> Thoughts?
> Chad
> ________________________________
> From: fluent-nhibernate@googlegroups.com on behalf of Andrew Stewart > Sent: Thu 8/14/2008 3:39 PM > To: fluent-nhibernate@googlegroups.com > Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
> Just committed this experimental metthod:
> var autoModel = new > AutoPersistenceModel(Assembly.GetAssembly(typeof(AutoMapTests))); > autoModel.AddEntityAssembly(Assembly.GetAssembly(typeof > (AutoMapTests)),t => t.Namespace == "FluentNHibernate.AutoMap.Test");
> Now that should add the ability to maps load all maps that are manually > created, plus automap the other objects. Now here comes the problem I have > at the moment, I have no easy way to tell what properties have been manually > mapped, so that I can ignore them when automapping. Does anyone know of any > easy way to find this out?
> var persistenceModel = new > AutoPersistenceModel(Assembly.GetAssembly(typeof(PlotMap))); > persistenceModel.AddEntityAssembly(Assembly.GetAssembly(typeof (Address)), > t => (t.Namespace == "Mdis.Entities" && ( t.BaseType == typeof(object)))); > persistenceModel.Configure(cfg);
The first assembly is the assembly containing your maps, the second is the assembly containing your entities (I'm assuming you have two assemblies for SoC, but there's no reason why these can't be the same). Then I've created an AutoMap which inherits from ClassMap, this is so I don't dirty up the base class with my little requirements, essentially what properties have already been mapped(to prevent duplication).
What happens is, first it loads in your automap's then in maps in extra unmapped properties and entities(hope that makes sense). So you only need to specify exceptions to the rule everything else will be mapped straight out the box as if by magic. Now my next challenge will be making this a bit more fluent and specifying conventions across the board as of Chad's suggestion below:
> var model = AutoPersistenceModel > .MapEntitiesFromAssemblyOf<AutoMapTests>() > .Where(t => t.Namespace == "FluentNHibernate.AutoMap.Test") > .ForTypesThatDeriveFrom<DomainEntity>(map => > {
> map.UseIdentityForKey(e => e.Id, "Id"); > });
Plus if anyone can think of a nice way to replace the contents of AutoPersistanceModel.AddEntityAssembly, which strict typing let me know.
I did a spike and got my head around it. Basically, you have a bunch of
generic methods and then you're treating them non-generically.
Will this be called directly by people, or is this mostly internal API
stuff?
I was able to create an IAutoMap rather than have AutoMap<T>,
IAutoPartMapper instead of the various part mappers (IAutoMapper was
confusing because there's an AutoMapper<T>, but it wasn't an
IAutoMapper, IAutoMapper is really something like IAutoPartMapper, etc).
Anyhow, if you use interfaces for these things and make them non-generic
(i.e. don't make it Foo<T>, just make methods like Foo(Type theType)).
Make the people-facing fluent interfaces generic <T>, but all the
internal stuff non-generic otherwise your life will be very painful (as
you've already found out).
I don't want to commit my spike code because it's not tested and it's
sloppy, but maybe we can pair on this sometime if you want, or if you
want to research this yourself, etc.
-c
From: fluent-nhibernate@googlegroups.com
[mailto:fluent-nhibernate@googlegroups.com] On Behalf Of Andrew Stewart
Sent: Friday, August 15, 2008 7:51 AM
To: fluent-nhibernate@googlegroups.com
Subject: [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
Hello
I've just checked this in and it seems to work,
var persistenceModel = new
AutoPersistenceModel(Assembly.GetAssembly(typeof(PlotMap)));
persistenceModel.AddEntityAssembly(Assembly.GetAssembly(typeof
(Address)), t => (t.Namespace == "Mdis.Entities" && ( t.BaseType ==
typeof(object))));
persistenceModel.Configure(cfg);
The first assembly is the assembly containing your maps, the second is
the assembly containing your entities (I'm assuming you have two
assemblies for SoC, but there's no reason why these can't be the same).
Then I've created an AutoMap which inherits from ClassMap, this is so I
don't dirty up the base class with my little requirements, essentially
what properties have already been mapped(to prevent duplication).
Example
public class PlotMap : AutoMap<Plot>
{
public PlotMap()
{
HasManyToMany<Service>(p => p.Services);
}
}
What happens is, first it loads in your automap's then in maps in extra
unmapped properties and entities(hope that makes sense). So you only
need to specify exceptions to the rule everything else will be mapped
straight out the box as if by magic. Now my next challenge will be
making this a bit more fluent and specifying conventions across the
board as of Chad's suggestion below:
var model = AutoPersistenceModel
.MapEntitiesFromAssemblyOf<AutoMapTests>()
.Where(t => t.Namespace ==
"FluentNHibernate.AutoMap.Test")
.ForTypesThatDeriveFrom<DomainEntity>(map =>
{
map.UseIdentityForKey(e => e.Id, "Id");
});
Plus if anyone can think of a nice way to replace the contents of
AutoPersistanceModel.AddEntityAssembly, which strict typing let me know.
> Will this be called directly by people, or is this mostly internal API > stuff?
The crappy code is only internal and tests should now fail if it's broken, which is nice to know. I think I know what you mean and I'll try and tidy that code up shortly, thanks for the offer to pair over this it may come in useful, but i'd like to have a go at it myself for now. I'll give you a shout if I get stuck though, if it's ok with you.
On Sat, Aug 16, 2008 at 1:02 AM, Chad Myers <c...@chadmyers.com> wrote: > I did a spike and got my head around it. Basically, you have a bunch of > generic methods and then you're treating them non-generically.
> Will this be called directly by people, or is this mostly internal API > stuff?
> I was able to create an IAutoMap rather than have AutoMap<T>, > IAutoPartMapper instead of the various part mappers (IAutoMapper was > confusing because there's an AutoMapper<T>, but it wasn't an IAutoMapper, > IAutoMapper is really something like IAutoPartMapper, etc).
> Anyhow, if you use interfaces for these things and make them non-generic > (i.e. don't make it Foo<T>, just make methods like Foo(Type theType)).
> Make the people-facing fluent interfaces generic <T>, but all the internal > stuff non-generic otherwise your life will be very painful (as you've > already found out).
> I don't want to commit my spike code because it's not tested and it's > sloppy, but maybe we can pair on this sometime if you want, or if you want > to research this yourself, etc.
> -c
> *From:* fluent-nhibernate@googlegroups.com [mailto: > fluent-nhibernate@googlegroups.com] *On Behalf Of *Andrew Stewart > *Sent:* Friday, August 15, 2008 7:51 AM > *To:* fluent-nhibernate@googlegroups.com > *Subject:* [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
> Hello
> I've just checked this in and it seems to work,
> var persistenceModel = new > AutoPersistenceModel(Assembly.GetAssembly(typeof(PlotMap))); > persistenceModel.AddEntityAssembly(Assembly.GetAssembly(typeof (Address)), > t => (t.Namespace == "Mdis.Entities" && ( t.BaseType == typeof(object)))); > persistenceModel.Configure(cfg);
> The first assembly is the assembly containing your maps, the second is the > assembly containing your entities (I'm assuming you have two assemblies for > SoC, but there's no reason why these can't be the same). Then I've created > an AutoMap which inherits from ClassMap, this is so I don't dirty up the > base class with my little requirements, essentially what properties have > already been mapped(to prevent duplication).
> Example
> public class PlotMap : AutoMap<Plot> > { > public PlotMap() > { > HasManyToMany<Service>(p => p.Services); > } > }
> What happens is, first it loads in your automap's then in maps in extra > unmapped properties and entities(hope that makes sense). So you only need to > specify exceptions to the rule everything else will be mapped straight out > the box as if by magic. Now my next challenge will be making this a bit more > fluent and specifying conventions across the board as of Chad's suggestion > below:
> var model = AutoPersistenceModel > .MapEntitiesFromAssemblyOf<AutoMapTests>() > .Where(t => t.Namespace == "FluentNHibernate.AutoMap.Test") > .ForTypesThatDeriveFrom<DomainEntity>(map => > {
> map.UseIdentityForKey(e => e.Id, "Id"); > });
> Plus if anyone can think of a nice way to replace the contents of > AutoPersistanceModel.AddEntityAssembly, which strict typing let me know.
I decided to tackle your problem from a different angle to Chad. It sounds like Chad went to the root of the problem by making non generic methods. I came up with a less fragile way of invoking the generic methods using reflection. My solution replaces this:
// Merge Mappings together var findAutoMapMethod = typeof(AutoMapper).GetMethod("MergeMap"); var genericfindAutoMapMethod = findAutoMapMethod.MakeGenericMethod(obj); genericfindAutoMapMethod.Invoke(autoMap, new[] { mapping });
With this:
InvocationHelper.InvokeGenericMethodWithDynamicTypeArguments( autoMap, a => a.MergeMap<object>(null), new[] { mapping }, obj);
Here is the implementation of that method:
public static object InvokeGenericMethodWithDynamicTypeArguments<T>(T target, Expression<Func<T, object>> expression, object[] methodArguments, params Type[] typeArguments) { var methodInfo = ReflectionHelper.GetMethod(expression); if (methodInfo.GetGenericArguments().Length != typeArguments.Length) throw new ArgumentException( string.Format("The method '{0}' has {1} type argument(s) but {2} type argument(s) were passed. The amounts must be equal.", methodInfo.Name, methodInfo.GetGenericArguments().Length, typeArguments.Length));
This is sturdier because a refactoring of the MergeMap method would flow to the lambda. Obviously it is still somewhat fragile because there is no guarantee that the right number of type arguments is passed, hence the runtime check.
The patch is attached to this email. I figure that you will probably want to go down the path that Chad followed, but perhaps this implementation will be useful trick when you don't have the luxury of modifying the API to be non-generic.
>> Will this be called directly by people, or is this mostly internal API >> stuff?
> The crappy code is only internal and tests should now fail if it's broken, > which is nice to know. I think I know what you mean and I'll try and tidy > that code up shortly, thanks for the offer to pair over this it may come in > useful, but i'd like to have a go at it myself for now. I'll give you a > shout if I get stuck though, if it's ok with you.
> Cheers
> Andy
> On Sat, Aug 16, 2008 at 1:02 AM, Chad Myers <c...@chadmyers.com> wrote:
>> I did a spike and got my head around it. Basically, you have a bunch of >> generic methods and then you're treating them non-generically.
>> Will this be called directly by people, or is this mostly internal API >> stuff?
>> I was able to create an IAutoMap rather than have AutoMap<T>, >> IAutoPartMapper instead of the various part mappers (IAutoMapper was >> confusing because there's an AutoMapper<T>, but it wasn't an IAutoMapper, >> IAutoMapper is really something like IAutoPartMapper, etc).
>> Anyhow, if you use interfaces for these things and make them non-generic >> (i.e. don't make it Foo<T>, just make methods like Foo(Type theType)).
>> Make the people-facing fluent interfaces generic <T>, but all the internal >> stuff non-generic otherwise your life will be very painful (as you've >> already found out).
>> I don't want to commit my spike code because it's not tested and it's >> sloppy, but maybe we can pair on this sometime if you want, or if you want >> to research this yourself, etc.
>> -c
>> *From:* fluent-nhibernate@googlegroups.com [mailto: >> fluent-nhibernate@googlegroups.com] *On Behalf Of *Andrew Stewart >> *Sent:* Friday, August 15, 2008 7:51 AM >> *To:* fluent-nhibernate@googlegroups.com >> *Subject:* [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
>> Hello
>> I've just checked this in and it seems to work,
>> var persistenceModel = new >> AutoPersistenceModel(Assembly.GetAssembly(typeof(PlotMap))); >> persistenceModel.AddEntityAssembly(Assembly.GetAssembly(typeof (Address)), >> t => (t.Namespace == "Mdis.Entities" && ( t.BaseType == typeof(object)))); >> persistenceModel.Configure(cfg);
>> The first assembly is the assembly containing your maps, the second is the >> assembly containing your entities (I'm assuming you have two assemblies for >> SoC, but there's no reason why these can't be the same). Then I've created >> an AutoMap which inherits from ClassMap, this is so I don't dirty up the >> base class with my little requirements, essentially what properties have >> already been mapped(to prevent duplication).
>> Example
>> public class PlotMap : AutoMap<Plot> >> { >> public PlotMap() >> { >> HasManyToMany<Service>(p => p.Services); >> } >> }
>> What happens is, first it loads in your automap's then in maps in extra >> unmapped properties and entities(hope that makes sense). So you only need to >> specify exceptions to the rule everything else will be mapped straight out >> the box as if by magic. Now my next challenge will be making this a bit more >> fluent and specifying conventions across the board as of Chad's suggestion >> below:
>> var model = AutoPersistenceModel >> .MapEntitiesFromAssemblyOf<AutoMapTests>() >> .Where(t => t.Namespace == "FluentNHibernate.AutoMap.Test") >> .ForTypesThatDeriveFrom<DomainEntity>(map => >> {
>> map.UseIdentityForKey(e => e.Id, "Id"); >> });
>> Plus if anyone can think of a nice way to replace the contents of >> AutoPersistanceModel.AddEntityAssembly, which strict typing let me know.
|
