Board index » delphi » Re: Value type framwork & calling specific setters

Re: Value type framwork & calling specific setters


2005-12-21 04:44:33 AM
delphi267
"Bart" <@>a écrit dans le message de news:
XXXX@XXXXX.COM...
| Joanna why are not you using objects as ValueTypes ?
I am !! The Value Type objets are kept in a list inside the base business
class. The properties are merely accessors to the actual values held in the
Value Type objects.
This approach allows *normal* coding of access to the properties from
outside of the business objects. You really don't want to keep on referring
to things like aCustomer.Name.Value when you can just use aCustomer.Name.
| Correct me if I am wrong but as I see it now it has several advantages:
|
| 1. You don't have to write all the getters and setters in the business
| object.
This is a false premise because having getters and setters allows you to do
validation specific to the type of business class that contains the
properties.
| 2. It is easy to add extra information i.e. max. length, min. value, max.
| value etc. etc.
This kind of metadata can be and is kept in the internal ValueTypes.
| 3. The value types can be a subject. So they are pretty easy to 'wire'
with
| standard controls
The internal Value Types do implement the Observer pattern and can
participate in the MVP framework.
There are two aspects to a business class :
1. The properties that client code talks to; this should be plain and
unencumbered by things like extra metadata and UI funjctionality.
2. The Value Types are made available but not through the "normal" pulic
class interface so that a data layer and UI layer can access all the
metadata, etc that those layers require but of which the client code has no
need.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 
 

Re: Value type framwork & calling specific setters

Quote
I am !! The Value Type objets are kept in a list inside the base business
class. The properties are merely accessors to the actual values held in
the
Value Type objects.
You are right ofcourse. This is what I overlooked
Quote
constructor TCustomer.Create;
begin
inherited Create; // initialises the value type list in TBO.Create
AddValueType('Name', TStringValueType.Create); <-- Here they are :)
AddValueType('Age', TIntegerValueType.Create);
// etc
end;
This approach allows *normal* coding of access to the properties from
outside of the business objects. You really don't want to keep on
referring
to things like aCustomer.Name.Value when you can just use aCustomer.Name.
This makes sense. What you are describing is the situation I have at the
moment. And I don't like it
Quote
This is a false premise because having getters and setters allows you to
do
validation specific to the type of business class that contains the
properties.
So valiadtion is done in the business object. Is this also the place for a
value conversion ? lets say on a form a user can select in a ComboBox: low,
medium, high and my BO has to written with 0.5, 0.75, 1.0
Thanks for your time Joanna, I think I almost got it :)
bart
 

Re: Value type framwork & calling specific setters

"Bart" <@>a écrit dans le message de news:
XXXX@XXXXX.COM...
| So valiadtion is done in the business object.
Certainly, some validation is done *in* the object, other validation may be
done outside as well, possibly triggered by the MVP framework responding to
trying to leave an edit.
| Is this also the place for a
| value conversion ? lets say on a form a user can select in a ComboBox:
low,
| medium, high and my BO has to written with 0.5, 0.75, 1.0
No, it is the job of the Presenter to translate the *real* value as
reflected by a property of the business object into something that can be
displayed. Selection of a UI value is translated into its corresponding
value by the Interactor within the MVP.
The BO should have no knowledge of translation, either for storage or
display purposes. Its purpose is to hold data and rules, pertaining to its
domain.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re: Value type framwork & calling specific setters

Thanks a lot for taking the time. I am getting there a little more with
my understanding. Bart's post addressed some of my issues also. First I
think I need to put this issue in our context.
Our framework is based on TCollection and TCollectionItem, with all
business classes being descendants of our descendant of TCollectionItem.
Without introducing interfaces I guess, that would eliminate the
situation like your frameworks, where business classes descend from
TBusinessObject.
I guess your TBusinessObject is equivalent to our TOurDataType where our
value types, TOurString, TOurBoolean, TOurDateTime, TOurDouble are
descendants of TOurDataType.
Quote
Every business object needs a list of Value Types to hold the values
behind the properties, the...THashedStringList is the
list that holds the Value Types.
I guess we could have the FValueTypes in TOurCollection.
Quote
This approach allows *normal* coding of access to the properties from
outside of the business objects. You really don't want to keep on
referring to things like aCustomer.Name.Value when you can just use
aCustomer.Name.
Yes, that was proving unwieldly and lead to the problem with the setters
not being fired that prompted my initial post in this thread.
Quote
There is no way of avoiding having to write getter and setter methods for
each property in regardless of what version of Delphi or even other language
that you choose.
Still trying to understand this fully, in trying to explain my confusion
more, I will refer to Bart's post and your response :
Quote
>| 2. It is easy to add extra information i.e. max,length,min,etc
This kind of metadata can be and is kept in the internal ValueTypes.
Ok. In our case, these properties will be part of TOurDataType,
TOurString, etc. But how can these be exposed? With max being a property
of TOurDateTime are you saying that then for every business object that
has a TOurDateTime property (1 or more) we would need to write getters
and setters for every instance of TOurDateTime (could be 100's across
all business objects)? I'd imagine this can not be what you are
proposing, but I can not see how else you are exposing this so called meta
data.
Thanks again,
Tom.
 

Re: Value type framwork & calling specific setters

Quote

2. The Value Types are made available but not through the "normal" pulic
class interface so that a data layer and UI layer can access all the
metadata, etc that those layers require but of which the client code has
no
need.

I don't understand this Joanna. When it is not public how is it done ?
Bart
 

Re: Value type framwork & calling specific setters

"Bart Janisse" <@>a écrit dans le message de news:
43a96b42$XXXX@XXXXX.COM...
| I don't understand this Joanna. When it is not public how is it done ?
The Value Types list is surfaced through an Interface that has a
GetValueTypes method.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re: Value type framwork & calling specific setters

"Tom Corcoran" <XXXX@XXXXX.COM>a écrit dans le
message de news: XXXX@XXXXX.COM...
| Our framework is based on TCollection and TCollectionItem, with all
| business classes being descendants of our descendant of TCollectionItem.
| Without introducing interfaces I guess, that would eliminate the
| situation like your frameworks, where business classes descend from
| TBusinessObject.
Basing your framewxork on TCollection and TCollectionItem is not a good
idea. Some business classes do not need this analogy and you are adding
behaviour from the VCL classes that is not necessary.
| I guess your TBusinessObject is equivalent to our TOurDataType where our
| value types, TOurString, TOurBoolean, TOurDateTime, TOurDouble are
| descendants of TOurDataType.
No, TBusinessObject is not the base class of the Value Type hierarchy, it
contains a list of Value Types. If we want a BO Value Type, then this, like
all the other Value Types contains a private field of the appropriate type.
|>Every business object needs a list of Value Types to hold the values
|>behind the properties, the...THashedStringList is the
|>list that holds the Value Types.
|
| I guess we could have the FValueTypes in TOurCollection.
No, you would hot have a list of Value Types in a collection, the list of
Value Types is held in the base business object class.
What is your reasoning behing choosing to derive from TCollection/Item ??
|>>| 2. It is easy to add extra information i.e. max,length,min,etc
|>This kind of metadata can be and is kept in the internal ValueTypes.
|
| Ok. In our case, these properties will be part of TOurDataType,
| TOurString, etc. But how can these be exposed? With max being a property
| of TOurDateTime are you saying that then for every business object that
| has a TOurDateTime property (1 or more) we would need to write getters
| and setters for every instance of TOurDateTime (could be 100's across
| all business objects)? I'd imagine this can not be what you are
| proposing, but I can not see how else you are exposing this so called meta
| data.
But of course you would have to declare accessors for every property of
every class. This is no more onerous than having to write property accessors
for every property regardless of its type to accomodate the validation and
business rules required as part of a business class.
Please look at the example code that I posted the other day for further
clarification. But don't think that you can get away with a 'no-code'
solution to a well-designed Value Type framework.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
 

Re: Value type framwork & calling specific setters

Thanks for the help.
Joanna Carter [TeamB] writes:
Quote
Basing your framewxork on TCollection and TCollectionItem is not a good
idea. Some business classes do not need this analogy and you are adding
behaviour from the VCL classes that is not necessary.
I would say that is probably arguable. The design is somewhat inspired by
Scott Ambler's Single table inheritance paper. We also use things like
Tcollection inbuilt sort which is pretty fast. This basis on TCollection
does lead to some restrictions on the business classes but works quiet well.
Quote
What is your reasoning behing choosing to derive from TCollection/Item ??
We have a lot invested in this framework now, which has been in use for
a number of years, so are not prepared to change it is design right now.
Quote
But of course you would have to declare accessors for every property of
every class. This is no more onerous than having to write property accessors
for every property regardless of its type to accomodate the validation and
business rules required as part of a business class.
We are working on a reg ex driven code generator to update our code base
for the value type scenario and we use a code generator to build our
objects so this would not necessarily be so daunting.
Quote
Please look at the example code that I posted the other day for further
clarification. But don't think that you can get away with a 'no-code'
solution to a well-designed Value Type framework.
Will have to knuckle down in the new year and come with with a solution.
Thanks for all the tips and advice and happy holidays.
Tom.
 

Re: Value type framwork & calling specific setters

Quote

The Value Types list is surfaced through an Interface that has a
GetValueTypes method.

I have to chew on this for a while and do some playing with interfaces. But
I like to get back on this later if it is not a problem
Bart.