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
-~----------~----~----~----~------~----~------~--~---
