RE: Objects and such

In order to achieve the desired effect from the code above, the

developer will need to

create a custom implementation of the "!=" operator for the Address

class (and presumably

the "==" also) which will of course be language specific.

Yes, but in c# we'd override the Equals and Hash methods and the
operators would fix themselves. In this example we would want address to
have value semantics, not reference semantics, you're correct.

Another way to do this without creating a new reference object is to

simply

use o.Customer directly:
if (o.Customer.ShipToAddress != o.Customer.MailingAddress)

Yup. But I'd expect that the JIT would compile out that object reference
anyway, so who cares. :)

although they do not separate the DB access from the final object.

Aarrgh!!! :) We've refactored the underlying IO code numerous times,
both fixing/optimizing IO paths and starting with reflection and moving
onto IL generation for the SetField method. I'm surprised you didn't
point out that SetField is defined on the base class, yet it's modifying
a field on a derived class. :)

Also, we can swap out the SQLServer implementation and swap in the
System i implementation and change complete IO paths this way. :)

This way you can regenerate the base class without losing the custom
code. How do you guys handle that?

Since the IO isn't in the derived class the only reason to regenerate
would be the addition of another column to the table, and it's simpler
to add the field and property by hand than to regenerate, so in short,
we don't. :)

-Walden