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

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.