]
>public void CanSaveChildEntities()
>{
>IList list = new List { new
> TestEntityB{Comment = "Test"}};
>
>new PersistenceSpecification(_pm.GetSession())
> .CheckProperty(e => e.Name, "Test")
>
.CheckList(e => e.Children, list)
.VerifyTheMappings();
}
/Peter
From: fluent-nhibernate@googlegroups.com
[mailto:fluent-nhibern...@googlegroups.com] On Behalf Of Paul Batum
Sent: den 16 september 2009 15:29
To: fluent-nhibernate@googlegroups.com
Subject: [fluent-nhib] Re: A
tomapping)
>
> /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
>
ncies, 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, a
Hm, yesterday I read NHibernate In Action, particularly section about
access to fields instead of properties, and didn't even think about
the possibility to use it.
I think this will work to a good degree. I can even use
IPropertyAccessor if needed.
Thank you, this is definitely better. I wonder
Whoops, got a bit happy with using resharper hints, the _children field
should not be declared as readonly.
On Sat, Sep 5, 2009 at 1:38 PM, Paul Batum wrote:
> Sergey,
>
> You do not have to use Reveal() for the cases you described. Say I have
> this entity:
>
> public class TestEntityA
>
Playtime,
Can you explain what you meant by this:
On Fri, Sep 4, 2009 at 9:41 PM, playtime wrote:
>
> This and the requirement that everything be virtual/overridable makes
> the Automapper useless to me in it's current form.
>
>
To my knowledge, we make our entites have virtual properties and m
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 _children = new
List();
public virtual IEnumerable Children
{
get
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
>> like Map(Reveal.Property("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/6c1fb736
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 wrote:
>
> Hm
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 w
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 s
I by the way, as far as I understand, if I do
mapping.Map(x => Reveal.Property("quantity"));
I also have to do
mapping.IgnoreProperty(x => x.Quantity);
so it's TWICE a work if I want a good design. Or, back to mapping
inside entities... Or, avoid AutoMapping at all.
So, to summa
14 matches
Mail list logo
