... I would suggest not worrying about hierarchies yet. You have a good start on the behaviors these things should provide... ... I don t get the sense fromMessage 1 of 49 , Feb 2, 2004View Source
> My quandry is in deciding whether to model the types as a hierarchyI would suggest not worrying about hierarchies yet. You have a good
> of entity objects, or to model the types as a hierarchy of value
> objects, with an attribute of the order entity to define the
> type. There may be some better approach I haven't thought of yet.
start on the behaviors these things should provide...
> A little more detail...I don't get the sense from this description that a hierarchy of
> There are three major types of orders...
> All three major order types are different in that that manage very
> different kinds of data...
> Then, for service orders, there are 10 or so subtypes... somewhat
> different in the data they track... though the workflows can be very
> different. The workflow is determined by the order type, as well as
> some details about the order...
> Finding orders for query and reporting is mostly based on either the
> merchant or the state of the order...
entities vs. values is an important question yet. If you think through
a couple of these specific scenarios, do you think you could implement
any one of them without too much trouble?
My only point was that the definition of entity in E/R modeling is not the same as that typically used in OO modeling. And it is sufficiently similar toMessage 49 of 49 , Feb 6, 2004View SourceMy only point was that the definition of "entity" in E/R modeling is not the same as that typically used in OO modeling. And it is sufficiently similar to cause some confusion.Eric-----Original Message-----
From: hemant sahgal [mailto:hsahgal@...]
I would like to point out that the E/R model is a logical model of the domain entities and their relationships (and not a data model).