Re: Long Life Objects

If I understand this correctly, your Dictionaries exist only in the DB
Access subsystem.

No, the dictionaries exist in the domain layer. They are contained in
a single instance domain object of type Company. I retrieve a dataset
from the RDB via the data access layer and build the dictionaries in
the domain layer.

They support requests in the problem solution for
particular Customer information and Contact information.

Yes.

The implication is that in the actual warehousing problem solution one deals with only
one Customer and Contact at a time. So the Dictionaries are effectively
a cache for the RDB.

Yes.

Why do you want to use the Dictionaries as buffers in the DB Access
layer? Is this a performance issue (i.e., read the DB once at startup
and emulate it in memory to avoid individual seeks)?

Yes that is the reason, I don't have a performance issue that requires
the use of this approach but it just seemed like a more efficient
design than pulling the same (relatively) static data over the wire
from the RDB repeatedly.

Is the application up 24x7 or heavily multi-user so that the same customers keep getting
re-accessed and you wish to avoid redundant DB accesses?

Yes to 24x7 and I would say light multi-user access. The RDB hardware
and network have an excellent spec.

So the only "address" is an eMail address string? (I assumed it was a
classic mailing address composed of {street, city, etc.}.)

Your assumption was correct, sorry I didn't change your diagram.
Address is a classic mailing address. I have designed email address as
a string attribute of Contact.

That brings me full circle to my questions about performance above. This
warehouse application may be doing lots of other fascinating things, but
accessing contact information seems like it is pure CRUD/USER
processing. It also seems like ad hoc processing in that the user is
going to provide an arbitrary name and you give back the Contact
information that is in the DB. That is exactly what RDBs do best and you
are emulating it in memory. If that is the case, I would be inclined to
forget about [Contact] completely. I would just invoke a DB Access
interface method like getContact(customerName, contactSelector) and let
the RDB do its thing.

Yes it does perform other tasks but it is mostly CRUD/USER processing.
It seems that I have been protecting the RDB when I should have been
putting it to work and saving myself the additional work of managing a
domain layer in-memory database. This in fact might answer the
thread's original question where I was seeking advice for the object
that should be responsible for creating my application's 'type'
objects. To recap, my Address object currently contains an AddressType
object. Although some AddressTypes are known at design time (billing,
delivery etc.), the app allows a user to create new ones via the GUI.
I cannot therefore build a class hierarchy of AddressTypes at design
time. Therefore my current design simply instantiates an instance of
AddressType with data from the RDB and that instance is held as an
attribute of an Address instance. This approach is substituting sub-
typing for a reliance on the unique ID AddressTypeID so that tests for
an address type must check the int based ID against an application
constant. For example, in the billing area I would need something
like:
const int BillingAddress = 3;
if (Address.AddressType.AddressTypeID == BillingAddress )

This seems messy but I cannot find a way to handle such application
'type' objects that are not known at design time. How do you deal with
this sort of situation?

.

Relevant Pages

  • Re: Designing web form processing system
    ... and I've some questions about the design of the first part. ... That sort of CRUD/USER processing has already been ... this part of the application is just accessing data from an RDB, ... responsibilities and behavior responsibilities of the underlying ...
    (comp.object)
  • Re: Conversion of data & associated logic from ISAM to RDB
    ... - Using any new tool, (Screen to GUIs, COBOL files to DBs etc., or as you ... So as part of the design planning inevitably you think of enhanced ways ... A "Relational purist" will be unhappy because the RDB is being constrained ... by the original ISAM DB design,, ...
    (comp.lang.cobol)
  • Re: Trade Press Needs to Talk with HP Disaster Tolerence Customers
    ... favorable article concerning Rdb in Datamation. ... or Oracle from improving their professional marketing of these advanced ... problem space in comparison to it's more popular competitors. ... I have repeatedly discussed the scientific basis of the design ...
    (comp.os.vms)
  • Re: Bussines objects
    ... > I'm not even going to continue arguing the OO versus RDB case. ... > source of design. ... > Joanna Carter ... > TeamBUG support for UK-BUG ...
    (microsoft.public.dotnet.languages.csharp)