I'm also having trouble getting field access working. If I have no setter for my list I get: ----> System.ArgumentException : Property set method not found.
My IHasManyConvention looks identical to your example below (I've also tried ReadOnlyPropertyThroughCamelCaseField). But, I have not tried the IAutoMappingOverride<>, and I can't see the point of it, my IList is mapped (works if there's a setter), it's just the access part that won't work. (I'd tried it if it was simple, but my configuration and testproject would get circular dependencies, I'm trying to work out how to use 100% automapping) /Peter From: fluent-nhibernate@googlegroups.com [mailto:fluent-nhibern...@googlegroups.com] On Behalf Of Paul Batum Sent: den 5 september 2009 05:38 To: fluent-nhibernate@googlegroups.com Subject: [fluent-nhib] Re: Automapping, protected, and problems with design Sergey, You do not have to use Reveal() for the cases you described. Say I have this entity: public class TestEntityA { public virtual int Id { get; set; } private readonly IList<TestEntityB> _children = new List<TestEntityB>(); public virtual IEnumerable<TestEntityB> Children { get { return _children; } } } I then map it: public class TestEntityAMap : IAutoMappingOverride<TestEntityA> { public void Override(AutoMapping<TestEntityA> mapping) { mapping.HasMany(x => x.Children); } } And use a convention to set all of these with the appropriate access modifier: public class HasManyAccessOverride : IHasManyConvention { public void Apply(IOneToManyCollectionInstance instance) { instance.Access.CamelCaseField(CamelCasePrefix.Underscore); } } In summary, use nhibernate's support for access modifiers to avoid using reveal. Paul Batum On Fri, Sep 4, 2009 at 11:17 PM, queen3 <sergey.prokhore...@gmail.com> wrote: I personally do not have major problems with private auto- properties.To me it is more helpful to have automatic discovery of private members of choice, whether those are fields or properties. Still, this is not a show-stopper and so I don't think I'm going to insist on this. The topic I wanted to discuss is more a philosophical/ design question, that with FNH the right way to go (with better entity design) is a bit harder than the worse one. On Sep 4, 4:03 pm, Stuart Childs <chil...@gmail.com> wrote: > >> like Map(Reveal.Property<MyEntity>("propertyName") - another complaint > >> is that it doesn't seem to look for fields, only properties). > > FluentNHibernate does not current support fields, at all. For more > info, see this thread:http://groups.google.com/group/fluent-nhibernate/browse_thread/thread ... > > If you wish to track the status of this issue, you can watch the > ticket created by Morten Maxild here:http://code.google.com/p/fluent-nhibernate/issues/detail?id=315 > > On Fri, Sep 4, 2009 at 7:12 AM, Mikael Henriksson<mik...@zoolutions.se> wrote: > > Personally I prefer the fluent mapping. It is so much easier to get up and > > running when working with an existing database schema or when there is a > > need to customize naming etc on tables. I honestly don't see the wickedness > > in auto mapping. :) > > > On Fri, Sep 4, 2009 at 2:03 PM, queen3 <sergey.prokhore...@gmail.com> wrote: > > >> Hm, something like IPropertyFinder would definitely be nice to have > >> for AutoMapping, so that I can for example tell to include members > >> named like "field" and don't touch purely internal ones like "_field", > >> and so on. This would make some of the issues above go away... except > >> for manual overrides where one still needs to use Reveal (this is a > >> way to include non-public properties in lambda expressions for FNH > >> like Map(Reveal.Property<MyEntity>("propertyName") - another complaint > >> is that it doesn't seem to look for fields, only properties). > > >> But how do you tell FNH/NHibernate to work with fields using > >> Conventions? > > >> By the way "virtual" is not AutoMapping but NH lazy-loading > >> requirement AFAIK. > > >> On Sep 4, 2:41 pm, playtime <playtime...@googlemail.com> wrote: > >> > I abandoned using the Automapper for similar reasons. > > >> > If your entities are dumb and look more like service DTOs, you can use > >> > the Automapper. > > >> > This and the requirement that everything be virtual/overridable makes > >> > the Automapper useless to me in it's current form. > > >> > You cannot have anything beyond simple length/format validation if you > >> > use setters which reduces domain entities to little more than service > >> > DTOs. > > >> > I always ensure nHibernate uses field access which is quite simple to > >> > do when you adhere to a field naming standard and use Conventions. > >> > [Using properties by default is the single most dumb thing about > >> > Hibernate that's been perpetuated in every related project but I'm > >> > sure that's been debated to death elsewhere.] > > >> > I also have no idea what Reveal does... *runs off to RTFM. > > >> > If the Fluent guys have time, I would like to see the Automapper's > >> > enitity finders constructor take a 'finder' class or 'criteria' class > >> > so that both schools of thought (and others I'm not familiar with) > >> > could be accomodated. > > >> > Of course, this only works for new projects anyway. It's back to > >> > mapping classes and full control when you're mapping to a legacy > >> > schema. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
