Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

> ## Guidelines for using SBOs

> The SBO has three fundamental purposes:

> - To let you define a single database transaction for a complex data set, including data from multiple tables all updated on the client in a single operation, either in a one-to-one or master-detail relationship.

> - To provide a place where you can define business logic that must examine data from all of those data sets at the same time.

> - Progress Dynamics supports dynamic SBOs. Dynamic SBOs support data logic procedures like SDOs.

> Note: When using the SBO as a data source, the `ForeignFields` property must be qualified with the name of the parent SDO.

> It is important to note that in most cases you should only use an SBO if records from all the tables are added or updated on the client and returned to the server together. If a user update to a single table on the client results in executing business logic that updates other related tables on the server, this does not require using an SBO.

> For example, if your application is browsing data in a master-detail relationship, such as `Orders` and their `OrderLine` records, but the two tables do not need to be updated in the same transaction, then you can and should continue to use multiple SDOs without the SBO container just as you would in earlier Version 9 releases. You can make the master SDO the `Data-Source` for the detail SDO and define the foreign key values that relate them. The SDOs will automatically be kept in sync as the master is repositioned, and users can update one SDO or the other. An update to either table from the client can execute whatever business logic it needs to on the server, including updates to any number of other related tables.

> However, if you really need to allow users to make changes to both master and detail on the client (even potentially multiple levels of detail) in the same transaction and to commit all of those changes at once, then you can use the SBO to represent the data relationships. Likewise, if you need to define business logic that looks at changes to both master and detail at the same time, then you can also use the SBO.

> It is entirely likely that your application will have places where you should use an SDO directly, and places where you should use that same SDO inside an SBO. For example, if at one point in your application the user can browse `Orders`, you should just use the `Order` SDO. If the application window just allows the `Order` to be updated, then you should also use the SDO by itself. If you want to show `OrderLine` records of the `Order` but not update them in the same transaction, then the `Order` SDO should be the `Data-Source` for an `OrderLine` SDO. If the application window allows one or more `OrderLine` records to be updated but does not allow updates to the `Order` at the same time, then you should use the `OrderLine` SDO. If you need to allow multiple `OrderLine` records to be changed together, then you can use the `OrderLine` SDO together with the Commit/Undo band of a SmartToolbar.

> But if your application logic requires that an `Order` and its `OrderLine` records be added or updated in the same database transaction, and that business logic must control and validate those compound updates, then you can use a SmartBusinessObject that contains the `Order` SDO (as `Data-Source`) and the `OrderLine` SDO (as `Data-Target`). Each SDO can continue to have its own business logic, which affects updates to that single object. Any additional business logic written in the SBO will be executed in addition to the logic in each SDO.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095