Your comments were very good, Larry.  And there is definitely a need for this type of functionality and these are the types of enhancements that will continue to strengthen StrataFrame in future major releases.  Thanks for all of your input!

Excellent description of the problem Larry!

I can see where Michael is coming from as this is something that I've been wrestling with since I started using StrataFrame. Prior to SF I had been using CSLA where it is common to have a single parent object that contains collections of child objects. All the logic that ties them together is contained in a single BO. The UI developer only sees the BO's strongly typed properties and methods but doesn't know anything about the underlying data structure or how it is all tied together; the BO is a total black box. The goal is to hide all that complexity from the UI developer. In Greg's example the UI developer would simply drop a single object on the form and bind the properties. He or she  wouldn't have to  worry about adding code to load the child objects or mess with creating FKs. That was all done by the BO developer.

One downside to this approach, however, is that you end up with a lot more business objects. CSLA starts with five or six base business objects. From there each "complex" BO is designed to exhibit a specific set of behaviors (which is one of the guiding design principles of CSLA). I feel that StrataFrame takes a more general (and likely more practical) approach to object oriented programming. BOs can be combined on a form to provide a specific set of functionality. The same BOs can be reused and combined with other BOs on another form to provide a different set of functionality. This approach requires more knowledge of the BOs and their underlying data structure on the part of the UI developer. In fact SF exposes items such as the contained data table that CSLA wouldn't (if it used data tables). The net result is that with SF you end up with BOs that aren't encapsulated to the same degree that some object oriented purists would like but does provide an extremely flexible environment for rapid development of real word business applications. Unless you work in a very large development organization, there probably isn't a need for such a high degree of encapsulation. It took me some time but I finally got to the point where I accepted the fact that SF works, just use it.  Having said that I would still like to be able to create a complex business object (combining customer and orders for example) and be able to bind a field to customer.orders.order_number in the designer.

-Larry

Unless I'm completely missing the point here, I'd likely just drop the 7 BOs on the form.



Make the primary one the primary BO of the form. I'd set the form's IncludeInForm... properties (e.g. IncludeInFormSaveType, etc) to AllBusinessObjects.



Then you a few lines in the primary BO's Navigated event to load the other six BOs.



Controls bound to the appropriate BO/field.



The last bit would be to programatically tie the six to the primary BO by setting the appropriate FKs, usually in the AddNew event for each BO.



Then this will allow you to use the maintenanceformtoolstrip, add/edit/save/undo/delete from all at once.



Of course, I could be missing something and this wouldn't work....

Micheal,

BOs are very extensible...they are ultimately just a class.  So one thing you can do is create a collection or a property that represents the other BOs that may need to be tied to the parent BO.  For example, lets assume that we have two tables, a Customers table and a CustomerOrders table.  I want to add a lot of logic within the CustomersBO to handle logic with the CustomerOrders table.

There are a number of things that you could do here, but the first thing that you MUST keep in mind is reusability and writing the code ONLY once!   So you may want to create a property on the CustomersBO table that accepts a CustomerOrders table instance which could be set at design-time on a form:

Now after you create this property and drop it on a form, you could then drop on an instance of a CustomerOrdersBO on the form as well, select the CustomersBO and the form designer will give you all of the instances of CustomerOrders that have been dropped on the form.  You can then reliable start creating code within your CustomersBO that references that property and deal with it however you would like.

This code is just some pseudo code to give you an idea.  You can think outside of the box a little here, but just keep in mind that it is VERY dangerous to add data logic into a form.  You immediately "bottle-neck" your application.  Encapsulation is king!

Thanks Trent. 

Most of my experience is in straight client-server development using a tool such as VB/VB.NET to create forms and (using .NET as an example) creating datasets that contain exactly what I need then basing forms on those datasets.  I have a little bit of experience in .NET separating code into distinct layers, namely presentation, business and data classes.  That type of coding is cumbersome initially but leads to easier maintenance.  The benefits of tiered development are well documented on your web site among others.  If we can use a tool such as StrataFrame to automate/streamline the creation of any of the tiers as part of the coding process we gain an important advantage.  I've also done a fair amount of SQL coding and scripting including stored procedures, triggers, etc.  That said, my employer is coming from Clarion which indeed is a very data-centric language similar to FoxPro.

I think am up to speed on the general concept of the BOs but the tutorials use simple examples.  Where I'm struggling is with the ability to use our table based BOs at the form level.  In my opinion it would be nice to be able to drop multiple business objects on a form and establish the relationships between them at the form level with minimal coding (similar to database modeling).  There are no junction tables between the table the main BO is based on and the other 6 tables/BOs.

Using the example I gave earlier, the form will have about 40 fields on it.  Only 7 of the fields can be bound to the primary BO for data display.  The other 33 fields need to pull their data from 6 other tables, with one BO per table.  Unless there's something I'm missing-- and I hope there is , I would have to put a lot of code at the form level to call functions in the other 6 BOs in order to populate the fields on the screen.  This is just for a screen to retrieve the data and display it for browsing purposes.  In order to create add and update functionality, I would also have to call different functions on the other 6 BOs in order to populate list boxes so that the user can choose a display value from the secondary BOs and populate a non-display value in the main BO.

This is why I was thinking that creating BOs based on a database view might be preferable.  What I'm seeking is a suggestion of how to handle the scenario I'm describing.  Would basing a BO on a view be the way to accomplish it?  Should we keep the primary BO as is (based on the primary table) but incorporate into it the code to handle the other six tables?  If VB would allow me to create a new BO that inherited from multiple other BOs and then extend the functionality I'd do that-- let me know if you know how to do that.

I feel like I must be missing something obvious.  I have to admit that I didn't read every bit of the StrataFrame help file and I only have about a year of experience with VB.NET on some very simple and small projects.  Am I overlooking something critical that would allow me to create a relationship between a single "parent" BO and multiple "child" BOs when designing the form and at runtime?  Is there a way to use the BusinessLayerLinkManager or another tool to accomplish this when there are no junction tables?

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.

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!