Modeling of Lookup Values and ORM

[Guest]

Modeling of Lookup Values and ORM

I know this is not the correct forum for object design patterns, but I
haven't found any design related newsgroups.

Scenario:

Customers (table)
-----------------
CustomerID
Name
CustomerTypeID
.... other properties ...

CustomerTypes (table)
---------------------
CustomerTypeID
Type

===================================================
So, if I am modeling a customer entity, how do I represent the Type of the
Customer based on accepted practices? The dilemma is that when it comes to
updating or adding a Customer it makes more sense to reference the
CustomerTypeID. However, when displaying data to the user I want to show the
string representation (CustomerType.Type). Should objects that have these
"lookup" values represent these properties as:

public struct NamedValue
{
public object Name;
public object Value;
}

???

How do you handle this with solutions you design?

 

[Joanna Carter [TeamB]]

"Nate" <[email protected]> a écrit dans le message de (e-mail address removed)...

| Modeling of Lookup Values and ORM
|
| I know this is not the correct forum for object design patterns, but I
| haven't found any design related newsgroups.

Some of us have requested such a group, let's hope MS come through

| Scenario:
|
| Customers (table)
| -----------------
| CustomerID
| Name
| CustomerTypeID
| ... other properties ...
|
| CustomerTypes (table)
| ---------------------
| CustomerTypeID
| Type
|
| ===================================================
| So, if I am modeling a customer entity, how do I represent the Type of the
| Customer based on accepted practices? The dilemma is that when it comes
to
| updating or adding a Customer it makes more sense to reference the
| CustomerTypeID. However, when displaying data to the user I want to show
the
| string representation (CustomerType.Type). Should objects that have these
| "lookup" values represent these properties as:

If you are wanting to do *proper* OO design, you will not start with a
database and try to create classes; this is the worst possible method of
designing classes.

The problem stems from whatis known as an impedance mismatch between
relational modelling and object modelling.

e.g.

class SalesOrder
{
string Ref;
Customer Customer;
ReadOnlyList<OrderLine> Lines
decimal Total;
}

class OrderLine
{
int Quantity;
Product Product;
decimal UnitPrice;
decimal Total;
}

Note that the OrderLine class has no reference to the SalesOrder class. This
is correct as the usual reference that you find in relational tables is only
there to satisfy the needs of a relational database in creating
master-detail links.

In the real world, a SalesOrder is a composition that contains a list of
OrderLines; OrderLines have no context outside of a SalesOrder and they must
live and die with the SalesOrder.

It is the job of a good ORM to map this difference between the composite
object model and the "reverse" relational model.

In your limited example, this mismatch is not so evident and it is a simple
matter of creating business classes that will match more closely the tables.

If I were starting from scratch, I would start with the class :

struct CustomerType
{
string Description;
}

class Customer
{
string Name;
CustomerType CustomerType;
}

Notice that there is no reference to an ID as this is really only needed as
a primary and foreign key for database persistence.

I use the concept of a base business class that contains a "property bag" of
"property objects". It is this property bag that contains the information
including the ID of the object when the object has been persisted.

If you don't want to go to the trouble of creating a property bag class,
then you can simply add an ID to each class, but you should not add a
"foreign key ID" to match the table that you would create to store instances
of the class.

struct CustomerType
{
int ID;
string Description;
}

class Customer
{
int ID;
string Name;
CustomerType CustomerType;
}

In this example, your ORM should contain a mechanism for translating the ID
held in the CustomerType into an integer column in the customer table.

Joanna