Much of the current design energy within StrataFrame is focusing on moving toward an Entity/Collection model that will follow the relationships defined within the database.  Therefore, you create a Customer business object which is stored in a CustomerCollection when you have more than one of them.  This Customer object then has a property on it called Addresses which is an AddressCollection.  Much more intuitive than the single-bo route. 

However, that doesn't much help you here and now, does it?  We do some stuff similar to this with our business objects that we create for reporting.  I can see if I can get together a sample of how we expose those properties.  You would have to use a BindingSource (a generic .NET one, not a BBS) to bind to the controls (like the rest of the world does ).  Essentially, you create a property on your CustomersBO called Addresses and it returns a BusinessBindingSource that contains a business object of type AddressesBO.  You then fill both of the BOs when you fill the customer record and the BindingSource knows how to access the Addresses property because it's a list.

I had a similiar discussion as well this week.     In fact I would like to see the BO Mapper get super intelligent and based on the Foreign Key relationships automatically link all of the objects together in a super class.   This is a feature that would be killer as part of the framework.    I'm sure that it isn't too hard to link the events and do it yourself but the time savings would be immense.  It would combine the power of Dataset style development but with Strataframe's unbelievable framework.

Thanks,

Richard

Hi Larry.

Funny this coming up now... I've been learning a lot about this subject lately, and will try to expose the ideas, so I can be part of the discussion and see if I can consolidate some knowledge.

What if you created an Object Model class, a shared class handling the transaction for you. You could call it from your form, no need to create an instance of it, as it is shared, pass on your BOs as parameters and process whatever you need to do in it. You can start your Transaction, do whatever in a Try/Catch, etc.

These Object Models could reside in you Business Library, with the BOs.

Would that be a layer of Business Logic you are looking for?

I don't really have any magical ideas about how to accomplish this. I've done both (individual BOs dropped on the form and using custom properties to access extended BO functionality) and neither is ideal, for the reasons you've stated.



It did get me thinking about what I'd like though



It seems to me that ideally, if a BO could have another BO as a property, and if binding could occur (your customers.address.street example got me thinking), it would be sweet. In the example, the CustomersBO would have a property of an AddressBO. This is of course possible now, but I don't believe there could be any binding in a form designer. This would continue to leverage the framework by using the BOs, but also allow for more complex scenarios. Not sure if this is a helpful idea....



I'm going to think on this some more. Great question Larry!

I've just completed a project and while it works well from the user's perspective, I'm not completely satisfied with the underlying design and was wondering how other SF developers address the following situation. SF provides a one-to-one mapping between a business object and data base table. However logically, a business object might be made up of a core database table and a number of associated tables. For example a customer might be represented by a core table that contains the customer ID and name along with an associated table that contains addresses.

The most direct approach to dealing with this is to drop all of the objects on a form and add the code to the form to keep the individual objects in sync and possibly update them all on a transaction. My issue with this is that it places what I consider to be business logic in the UI.

Another approach is to create a complex business object based on the core table that exposes the associated tables as properties. This allows all of the logic that maintains the relationships to reside in the complex BO. The problem with this approach is that you cannot bind to a property such as 'customer.address.zipcode'. This can be addressed by exposing the individual properties of the contained business objects as custom properties of the complex BO, but you have to manually code the custom properties and property descriptors. And if you change an underlying table you have to update all that custom code. While I feel this approach provides a more object oriented design, all the extra manual coding undermines the productivity gains of the framework.

Any comments and/or suggestions would be greatly appreciated