I'm new to StrataFrame.

My company has created and compiled BOs as one BO per database table.  I'm designing a single form that has to retrieve data from seven different tables, so there are seven BOs on the form.  It would be very difficult to have multiple versions of a table-based BO with the same parent but different child BO objects.  Because of this, none of these BOs are related to any of the others by the Parent-Child relationship properties. 

The form uses a primary BO and passes parameters from the main BO to the other six BOs to retrieve lookup values for fields on the form.

I see that in your tutorials/samples that the BOs are table-based.

As a developer, I have to put a lot of extra code at the form level to update all of the fields on the form that use data coming from the BOs that are not the primary BO.

It seems that it would be easier to base the form on a single database view that already contains the main table values and the lookup values - this way all of the business logic and data can reside in a single instance of a single BO.  This would also reduce the amount of form level code by a large amount.

What is the recommended best practice for designing and creating BOs-- view-based or table-based?

Thanks!

I am not sure what environment you are coming from, but it sounds as though you may have experience in a data-centric language such as VFP or something of that nature based on the form driven example you gave.  We too came from a data-centric language and as we moved forward changed the way we think application wise, which as first we thought was painful but as we moved forward learned that the disconnected data, totally seperated tiers approach was much faster and more flexible....it just took some time to change our way of thinking.

I think that is where you may be in your development cycle and moving forward from different development standards that you have used in the past.

It really is not recommended to create any logic that relies too heavily from data manipulation on the form side as you become "form-locked" when you later want to have that some logic and functionality in another location in your app.  So it is definitely best to house your logic in BOs....and....to not have too much logic which "bogs" down your application because there is so much logic in a single location which creates a bottle-neck.  In short, you will have better performance and a better development experience if you spread your logic out into smaller entities like a BO per table or smaller view.

We have developers who do both and some use more views than others.  I will warn you though that creating too heavy a view based development environment can cause a much more complicated development environment and introduce a number of downstream issues just as it relates to SQL Server and creating an encapsulted data environment.  So more smaller pieces is always going to work better long term than fewer large pieces....if that makes sense.