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