Mike,

>Maybe I'm thinking wrong, but if you set up relationships in the form, it makes sense (to me) that you'd specify how they're related in the same place. Also, setting the .ForeignParentKeyField in the business object implies some knowledge of another biz object, which makes your biz object less autonomous and reusable.

I like to think of it this way...when you create a data model you are typically modeling the attributes of real-world entities (Customers, Inventory, Payments, etc.). Foreign key fields establish links between real world entities. When you do your object modeling you are modeling both the attribues and behavior of real world entities, so the relationships you define in your data model often reflect relationships defined in your data model. Relationships can change in the context of the user interface based on which objects you are using...that's why we allow defining of relationships at the UI level. However, for more persistent relationships (Invoice--nique)>Invoice Items, Order-> Order Items) you can define these within the business objects. Typically, you would have the parent business object instatiate and register the child business object. I would recommend doing this only if you ALWAYS use these parent/child objects together.

There is really no break in encapsulation to allow a child object to know about its parent(s). In nfact, when you do CRC card modeling (a classic OO modeling techique) you model Classes, Responsibilities, and Collaborations. The Collaborations define which objects and services are needed by a business object in order to fulfill its responsibilites. I think letting this information (such as foreign parent key field) bleed out into the UI would be breaking encapsulation. If you have scenarios where you want to register a business object with multiple parents, you may want to add methods to the child object that register the child with the parent and set the appropriate ForeignParentKeyField.

Regards,