Re: Long Life Objects

Hi Lahman
Thanks for responding. I enjoy reading your posts and understand at
least 9% of them with my current knowledge :-)

What problem is the application trying to solve?

It is a warehouse application that includes a basic contact management
element. One Use Case extract might be "A Customer Contact phones the
Company to order a next day delivery Service for a stored pallet of
goods."


I am getting hung up on the terminology here (e.g., "Dictionary"). It
sounds very much like you are trying to emulate an RDB and the
Dictionaries are just surrogates for table indices.

So I am. One of your other posts taught me the valuable lesson of
solving the problem without considering RDB persistence, which should
be handled in isolation. Before this I would drive the design from the
database and I now see how this is a poor approach. I suppose that the
reason I have unwittingly created an application RDB is because my
thought process for the implementation of the Use Case above, for
example, is:

1) I will need the Customer, Contact and Service(next day delivery)
objects for this problem.
2) All entities are persisted in my RDB using a surrogate key of type
int which is also used as the materialised entity's ID, i.e.
CustomerID = 87.
3) These entities are rarely updated but frequently read so I will
place them all into a Domain layer Dictionary at application start-up
using the ID for the key, i.e Dictionary<87, customer>.
4) I can now contain these Dictionaries in the application's start-up
object (Company) without hitting the RDB until a change is notified in
some way at which point I can refresh.


Is this what the problem space looks like?

1
[Company] ----------------------+
| 1 |
| |
| R1 | R4
| |
| has | references
| * | 1
[Customer] [ServiceCatalogue]
+ customerID | 1
| 1 |
| |
| R2 | R5
| |
| has | organizes
| 1 | *
[ContactInfo] [Service]
+ phoneNumber + serviceID
+ eMailAddress
| 1
|
| R3
|
| includes
| 1
[Address]
+ street
+ city
+ state


Almost. Each Customer has many Contacts which are physical people.
Each Customer has many Addresses. A contact belongs to one Address.
ServiceCatalogue is spot on.

1
[Company] ----------------------+
| 1 |
| |
| R1 | R4
| |
| has | references
| * | 1
[Customer] [ServiceCatalogue]
+ customerID | 1
| 1 |
| |
| R2 | R5
| |
| has | organizes
| * | *
[Contact] [Service]
+ phoneNumber + serviceID
+ eMailAddress



.

Relevant Pages

  • Re: Long Life Objects
    ... Dictionaries are just surrogates for table indices. ... solving the problem without considering RDB persistence, ... I will need the Customer, ... The implication is that in the actual warehousing problem solution one deals with only one Customer and Contact at a time. ...
    (comp.object)
  • Re: Relational database & OO
    ... It really doesn't matter to the time management problem solution whether the data is persisted in an RDB, an OODB, flat files, or clay tablets. ... So one could regard the DB Access subsystem I proposed as being a PSE from the perspective of the problem solution. ... I argue that the DB Access subsystem needs to deal with the particular persistence mechanisms that are at hand. ... Here is a basic example that you may find in a customer care & ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... Solve the customer's problem first and then worry about how objects in that solution will map into tables in the RDB. ... If addresses are stored in a separate table, then the Customer_Address_ID should be in the Customer table, not the Order table. ... Product, not the OrderLineItem. ... access subsystem to properly access the RDB to obtain the information, ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... > The first thing to do is forget about what the RDB looks like. ... > depends on the Customer identity, ... > Product, not the OrderLineItem. ... > To do that the persistence access subsystem needs to know more about ...
    (comp.object)
  • Re: Help! Difficulty understanding DB -> Object mapping
    ... If addresses are stored in a separate table, then the Customer_Address_ID should be in the Customer table, not the Order table. ... That's because things like product descriptions are unique to the Product, not the OrderLineItem. ... That allows you to address performance problems in RDB access in that subsystem or layer so that it does not affect your problem solution logic. ... The persistence access subsystem needs to map that notion of Order into the actual tables in the RDB. ...
    (comp.object)