Of particular concern are the following:

1) Is the Business Object mapper designed to recognize and implement a class/BO that consists of say 2 or 3 tables sharing a primary key with a discriminator?  For example Contact --> Employee--> Manager.  In other words does it support subtyping in the DB model out of the box? (and i dont mean can it be forced to work somehow )

2) My data model is also pretty normalized.  For example, given a Contact Table(person, or organization), a ContactInfo table(phone number, postal address, or eaddress), and a ContactInfoAlias(home phone, work email, etc.) with a link table between Contact and ContactInfo that also has a foreign key reference to the ContactInfoAlias (with the intent being to assign contactinfo rows to contacts and give them a nice name) does Strataframe seem like the right tool for the job?  I have done some searching of these forums and had seen mention of something called a linkmanager (i think) - which handles many to many relationships.  Can someone explain those a little bit, how they are used and their intended purpose within the framework?

In addition to handling contact info with link tables, many other things in the data model are implemented this way, for example Party Roles, relationships between those roles, etc... it gets a little hairy.  Would this be a problem for the BO mapper?

Finally, what kind of projects would you say are not a good match for Strataframe (be honest)?

Thanks alot!

Geoff

As for the business objects and the BusinessLayerLinkManager, business objects can only have one relationship, but a business object can belong to several link managers, so you should be able to effectively map as many relationships as you need.

Contact

ContactInfo

ContactInfoAlias

ContactContactInfoLink(ContactID,ContactInfoID,ContactInfoAliasID)

Tnks again!

For example, one of our users had this scenario this morning.  He had a Group table, Organization Table, and a link table named GroupOrganization.  So the Link Manager properties look somthing like this:

In this example the foreign and primary keys are defined as well..so when the GroupBO1 table is filled, it will automatically fill the Link OrganizationBO1 and GroupOrganizationBO1 tables.  This control gives you a lot of control when dealing with very normalized data structures since most times you are dealing with a foreign key of some sort.  Just so you can get a visual, below is another image showing the controls dropped on the form:

The properties show above are from the BusinessLayerLinkManager1 control in this image.

It seems lke the linkmanager would work great in a simple link table with 2 foreign keys..but in my case the ContactContactInfoLink actually has a reference to another table as well, the ContactInfoAlias table...is all lost?  It seems to me that this would be pretty common scenario - where not only are you creating a many to many relationship, but describing that relationship in some (normalized) way.

Not at all...just create another LinkManager class.  They can "piggy-back" each other so to speak.  When one is loaded it will create a ripple effect.  So you can basicallly go as deep as you want.

The team discussed options, took input from a couple of other customers in the class, and later that month they posted support for updateable views (using 'instead of' triggers), which was what we had recommended as the most maintainable solution.

Now, they posted it, but I have not been able to get back to my original project that required it, so I can't tell you with 100% certainty that all is working, but I am 90% sure based on what is in the UI and simply the fact that MicroFour is telling us that it works.