> Then make sure that either ABusinessObject has the property name too, or the
> child classes are kind enough to implement this functionality by
> implementing an abstract protected method that ABusinessObject can call.
My business objects are kind enough to provide the attribute. The
point of ABusinessObject is to provide a generic solution for all
business objects. Of course it would be more efficient if every
property handled the NotifyPropertyChanged event themselves, but then
I have peers who would screw up more than often. The abstract
protected method is a good idea, but it would cause the same
suffering, since you would have to convert column names to property
names, anyway. It gives me the benefit of a speed boost and the
guaruntee of existence. But, it also forces all my business objects to
implement the abstract method . . . I hate to put that responsibility
on my peers; they are much more comfortable with a simple attribute.
> Am I being too obvious here? What you want is of course possible, but it's a
> pointless headache. You're giving a class a responsibility it can't fulfil
> unless it grovels around in data that doesn't belong to it, which is usually
> a sign you're putting the responsibility where you want to see it instead of
> where it belongs.
How can an abstract class that is part of a library possibly predict
what users of that library can and will do? I simply provide the
functionality *if* they provide the attribute. It is like a membership
card, or something. Fortunately, I have a custom code generator
provided with my library that will generate most of my business
objects for me (attributes included). I feel the same way, though; I
feel like my code is reaching out, trying to find its way in a dark
room. However, I use reflection extensively in my library to provide
features that would otherwise be impossible or require complex
generics. My main concern is keeping my peers using my library.
We recently tried to use my library in Windows Forms and there were
certain limitations that meant using my code was "harder". I want to
provide a certain level of automation to prevent regular, common
mistakes (which are extremely common in my case). So, I am trying to
extend my library to support validation, error reporting and property-
changed events. Its the property-changed events that are causing all
the problems. If I didn't already have a heirarchy tested and proved,
it wouldn't be too much to ask my peers to write their business
objects with all the bells and whistles. I mean, you could avoid the
whole issue involving getting a property with a column name. But then
I have to trust my peers to be consistent, which is hard enough for me
to do. But how much do I want to depend on meta data, for the same
reason?
> Iterating over metadata *every single time a property is updated* is just
> wasteful. Of course you could optimize it by iterating just once... but then
> you'd have to cache the results, so you're back to my "make sure
> ABusinessObject has the property names" recommendation.
My thought was that NotifyPropertyChanged events are interface driven,
anyway. Interface equals little need for speed. However, I think I
might try caching the results, since they won't change. There is
always going to be the problem when an extensive amount of work is
done a business object behind the scenes before the interface regains
control. I don't know, I still feel like I am stretching.
Thanks for the insight,
Travis
> --
> J.- Hide quoted text -
>
> - Show quoted text -