>> 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/6c1fb73618de4fa1?hl=en 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 -~----------~----~----~----~------~----~------~--~---
