Hi,

in one of the previous posts was mentioned "a wrapper business object" that would allow to create a business object having data/columns from several tables.

The BusinessObject = 1 table is slightly problematic in the case when you would need to create a business object that would include columns from several tables (a SQL join)  and perhaps some computed fields (some computation rather done in the database than in the application).

In a Oracle environment would

a) this kind of wrapper solve this problem or
b) DDT bring any help on this issue
c) something else...? 

Lastly, is this true: the data structure of the business object is just a place holder and the query populating the data structure can be whatever, e.g any SQL-statement? If this true, then it would be possible to create just some dummy tables/views into the database. However, a wrapper approach would perhaps be "cleaner" as it wouldn't add anything to the database.

Kari
 

Yes, a wrapper business object is generally the way to go.  Basically, you can define a table in a "dummy" profile in the DDT and use that table as the structure for the business object.  This would allow the BOMapper to create the strong-typed properties rather than you having to do them by hand.  Also, yes, the internal DataTable of the business objects is flexible, so you can have extra columns within the business object that do not have corresponding strong-typed fields on the business object.  These extra fields can be retrieved through the Item (default indexer) property on the business object, so, if you add an extra column to the business object when you execute a query, say a count or something, you can access the column's value like this:

MyBO("CountColumnName")
or
MyBO.Item("CountColumnName") '-- Visual Basic

MyBO["CountColumnName"] //-- C#

So, a "wrapper" business object is one that does not directly correspond to a table or view in the database, but to a "dummy" table in the DDT that matches the structure of a query that is a join of multiple tables.

Hi,

ok, so this would require the use of DDT and as such there is now way to "combine" two business objects. Therefore - in Oracle world - the same can be achieved by just creating a table with the required "business object"-layout. The result is not optimal as it results in creating objects in the database that are not required.

It would be nice if a business object could be based on a SQL-statement...

Kari

The reason this would not work is due to the update.  This is really no different than a view...however, a view can be updatable which would support the logic behind INSERTs and UPDATEs.