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

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?

Thanks,

Richard

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.

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.

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.

Basically what I ended up doing in my last project follows Paul's approach. Rather then expose the properties of the contained BOs as custom properties in my complex BO, I dropped the individual objects on the form and wired them up to the contained objects (exposed as properties). This solved the data binding issue but is still not as clean a solution as I would like.

I like Richard's comments regarding a super intelligent BO Mapper that understands Foreign Key relationships and is able to link all of the objects together in some super class along with all the persistance logic. This is similar to a competing framework from a company here in the San Francisco Bay area. However I'd settle for the ability to define my own super class in BO Mapper telling it which objects to incorporate, have it generate a class that contains the individual objects along with all of the properties to support SF data binding, and leave the relationship coding to me. I believe this follows what Greg was suggesting. Coding properties is so boring and time consuming and having BO Mapper create them and doing the data binding in the form designer are such great features.

Ivan's idea of using a shared class to handle transactions is something I hadn't thought of but I think I would still need a complex object to handle the specific relationships between the objects I combined. For example in my last project I had an ActivityLog object that's not exposed to the user but get updated depending on the actions taken on the complex BO.

Long term it seems like the Entity/Collection model will address many of these issues. In the meantime I'll explore the suggestions made by Trent and I'd like to see the sample that Ben discussed added to the samples library on the forum.

Thanks again for all the comments.

-Larry