NHibernate CodeCamp Talk – Source Code

Posted on by

I have published the source of my Code Camp talk here. Check it out and post any questions.

Thanks to everyone who showed up for the NHibernate talk. It went really well and everyone had tons of great questions. Feel free to post feedback here, both positive and negative, so the next time I give this talk, it will be even better.

For those of you that just want a little more guidance on NHibernate, here are some good links:

Also, thanks to the coordinators of Richmond CC. I had a great time.

5 thoughts on “NHibernate CodeCamp Talk – Source Code”

  1. Thanks for the great talk on NHibernate at Richmond!

    I have a followup question. It appears to me that NHibernate is setting “IsChanged” equal to True upon a call to “List”. As you may expect this renders that property useless for change tracking. From my experience with CSLA, there is usually a way to tell if the property is being changed during Load or upon a user of the object actually changing something. “Dirty” was never the case after a “Fetch” from the database, because a local variable was set for each column, not using the public Setter method.

    Do you see this same behavior?

    Thanks again,
    Brian

  2. Do have some sample source code I could look at, maybe a small piece or some psuedo code. If I could see the code, the query, and the mappings, I might be able to help a little bit.

  3. Sure… here is a chunk of the entity (created by MyGeneration) where you can how IsChanged is effected by the public property setter:

    public virtual string EmployerName
    {
    get { return _employerName; }
    set { _isChanged |= (_employerName != value); _employerName = value; }
    }

    Mapping of that column is really irrelevant, but here it is for context :

    @lt;property type=”string” length=”50″ name=”EmployerName” column=”`EmployerName`” /@gt;

    A quick way to see what is happening, is just set a breakpoint in one of your entities public setters and call List@lt;@gt; on it.

    Thanks again

  4. That’s because NHibernate uses the setter to set the value. It is possible to change this behavior though.

    http://nhforge.org/doc/nh/en/index.html#mapping-declaration-property

    Read the access/naming strategies section. This will tell NHibernate how to access the property.

    <property name=”EmployerName” access=”nosetter.camelcase-underscore” />

    This will tell NHibernate, don’t use the setter, instead use the field that is the camel-cased version of the property name, prefixed with an underscore.

    Make sense? It’s a weird syntax, but it works like a charm.

  5. Thanks so much! I would have never thought the mapping was at work here. I should have listened better.
    All good now.