2009 Jun 08 6:41 PM
I have used persistent classes before, but I have never implemented persistent subclasses. It seems that there is relatively little written online about persistent subclasses. Its my hope that the following will spur some discussion (maybe if I suggest it is impossible, Thomas will ring in with another classic pearl).
A tad bit of background. We are building an application designed around object based principals. In u2018old termsu2019 we have two sets of master data and transactions they jointly participate in. In new terms, we will have two main classes representing the master data, and their interaction will be modeled through an association class. My problem/question concerns the right way to implement.
I have immensely watered down an example as a talking point. Our real world application had multiple u2018keyu2019 values (although all at the top level), many subclass specific attributes, a host of methods, and at least one more level of abstraction.
[Example Class Diagram|http://www.duke.edu/~michaelm/WidgetClass.jpg]
The example has a generic superclass, Widget, and a couple of subclasses. Widget would never be instantiated u2013 furthermore, only u2018leafu2019 subclasses would be insantiated.
IdNumber is the only u2018keyu2019 attribute u2013 the subclasses do not extend the key
name is a common attribute
StandardWidget would be instantiated. It includes the attribute buzzerType
DeluxeWidget would also be instantiated. It does not include buzzerType, but has its own bells and whistles
again, our real world example has many attributes and many subclasses of u2018widgetu2019.
I also wonder what the underling tables might look like u2013 two ideas come to mind - one sparse, one more normalized.
[Possible Persistent Tables|http://www.duke.edu/~michaelm/UnderlyingTables.jpg]
I would love to hear from anyone that has actually done this, or who has access to documentation specific to sub-class persistence. I am particularly interested in how we define our classes and persistence and what the underlying tables should look like. Your thoughts and ideas are welcome.
I have a number of other, targeted questions, and I will ask them under separate cover as is the forum policy, but I think there could be some very active and mutually beneficial discussion around this topic.
I'm not sure how we make it happen, but I would gladly enter into more discussion of these concepts, view a webcast, etc.
I have used persistent classes before, but I have never implemented persistent subclasses. It seems that there is relatively little written online about persistent subclasses. Its my hope that the following will spur some discussion (maybe if I suggest it is impossible, Thomas will ring in with another classic pearl).
A tad bit of background. We are building an application designed around object based principals. In u2018old termsu2019 we have two sets of master data and transactions they jointly participate in. In new terms, we will have two main classes representing the master data, and their interaction will be modeled through an association class. My problem/question concerns the right way to implement.
I have immensely watered down an example as a talking point. Our real world application had multiple u2018keyu2019 values (although all at the top level), many subclass specific attributes, a host of methods, and at least one more level of abstraction.
[Example Class Diagram|http://www.duke.edu/~michaelm/WidgetClass.jpg]
The example has a generic superclass, Widget, and a couple of subclasses. Widget would never be instantiated u2013 furthermore, only u2018leafu2019 subclasses would be insantiated.
IdNumber is the only u2018keyu2019 attribute u2013 the subclasses do not extend the key
name is a common attribute
StandardWidget would be instantiated. It includes the attribute buzzerType
DeluxeWidget would also be instantiated. It does not include buzzerType, but has its own bells and whistles
again, our real world example has many attributes and many subclasses of u2018widgetu2019.
I also wonder what the underling tables might look like u2013 two ideas come to mind - one sparse, one more normalized.
[Possible Persistent Tables|http://www.duke.edu/~michaelm/UnderlyingTables.jpg]
I would love to hear from anyone that has actually done this, or who has access to documentation specific to sub-class persistence. I am particularly interested in how we define our classes and persistence and what the underlying tables should look like. Your thoughts and ideas are welcome.
I have a number of other, targeted questions, and I will ask them under separate cover as is the forum policy, but I think there could be some very active and mutually beneficial discussion around this topic.
I'm not sure how we make it happen, but I would gladly enter into more discussion of these concepts, view a webcast, etc.
2009 Sep 24 9:22 PM
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |