Re: Objects and such

On 10/26/07, Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx> wrote:

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.

I was trying not to get language specific, but the point is that some
additional work is required for this to happen.

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. :)

OK, I can't argue there. :-) And again, I was really posting for the
uninitiated.

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. :)

Well gosh, I can't think of everything! :-D

Also, we can swap out the SQLServer implementation and swap in the

System i implementation and change complete IO paths this way. :)

I'm actually in the process of re-engineering a Database Agnostic layer so
that the application(s) can support multiple DB platforms. I first did this
with iHOC, (http://www.ihocquery.com) and I know I can improve upon it. I'm
also looking at DataDirect's collection of ManagedProviders, mostly so I
don't have to worry about distributing or requiring iSeries Access. I'm
still having the problem outlined in this article:
http://www.developingfor.net/net-20/ibm-iseries-net-managed-provider.htmleven
though we have upgraded to V5R4 on one of our boxes.

And I wasn't terribly clear when I said CSLA doesn't separate the DB access:
the business methods include all the methods for reading, updating,
deleting, etc., but the actual code execution requests are passed on to a
database layer via Stored Procedures. So by not separating, what I mean is
the method calls are still in the BusinessObject, along with the Stored
Procedure names, but the BusinessObject itself has no knowledge of the
target Database and the code is not database specific.

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. :)

Yes, I agree that the only real time I would regenerate is if the Database
layout changed, but in new product development that may happen a lot (until
the Database schema is solidified).

I'm still working on the final development model for all this, so this gives
me lots to add to the pile. Thanks!