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

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

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 am not sure that the entity collection stuff would resolve your problem entirely.  Though it might help, and what Ben was talking about as it relates to our reporting and the way we setup or BBS datasources, this is still going to require some manual code at some point.

In our medical software, we have a PhoneNumbers table that can be used by basically any parent table that has the need for unlimited phone numbers (we actually use it for any parent table that has a phone number period).  So now let's assume that I am on a patient record and I want to retrieve the primary and secondary phone numbers for reporting or display purposes (or even to update).  We expose a custom property for Primary and Secondary as these are the two that you generally deal with, but we have a shared class that all BOs that need to deal with phone numbers uses.  We also have a PhoneNumbers property that has all of the phone numbers for that patient that exposes an object model for the phone numbers (i.e. a PhoneNumber class that has all of the properties that relate to a phone number).  The only reason we have more than one property is for ease of display as it relates to items such as a report.  The PhoneNumbers collection is generally what we deal with as it relates to binding, etc.

This still aludes to a entity/object type of interface, and there will always be some level of manual setup, but if there is a structure change, the BO will not have to be modified, only the shared class that talks to the PhoneNumbers table directly.  I hope that makes sense.  But you are ALWAYS better of putting this code in an object model or BO or base BO rather than in a form so that you do not have to "reinvent the wheel" over and over again.

Hi guys

I have wrestled with the same problem.

At first was was doing as Larry stated and using the form as a container to house the logic to keep the releated business objects in sync as well as specific logic such as creating child records or whatever and keeping the business ruled in the business object.

Then I tried putting logic directly into the business object but this can get really hairy and caused me to have things blow up in my face.

What I am trying now is to put everything into a "super" class that is made up of several business objects. It basically acts like a business object container and contains logic specific to that entity. It kind of adds another layer to the business layer I leave the SF business objects in charge of common stuff such as required fields and table specific business rules and I add code that is specifc to a group of related business objects in the super class.

For instance I have a customer class that contains CustomerBo,AddressBO and several more business objects I also have and Employee class that contains EmployeeBo,AddressBO and several others. And I have logic that is common to all addresses in the regular SF addressbo and logic that is specific to a customer address in the that super class.  To have databinding work you still have to drop whatever business objects on a form and then wire them up to the business objects contained in the super class, and everything works fine.

Think of what I am doing as a container like the SF form except it is a class that inherits componentmodel.component instead of windowsforms.form . U drop you business objects into the class then write whatever code you need to make them play together the same as you would do if you dropped them on a form.

I hope this makes sence.