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. 

Hi,

but it wouldn't need to be updatable , you could use this e.g. when displaying lists that are not supposed to be updated. An other way of doing this is to have the possibility to specify which table to update e.g. if the query is a multi-table join.

One way of doing this is then if it would be possible to join business objects.

Kari

ps. Reason for my question is that I have a background in databases and would a) let the database to do as much work as possible b) keep the database clean and avoid any unnecessary stuff (e.g. views) that are not actually needed.

In the case that it does not need to be updated, all you need to do is create a query that brings back whichever fields that you need.  A query does not have to match the strong-typed fields properties.  You can access the field through the BO like this:

MyBO.Item("MyFieldName")

This same method is used when loading a list so you do not need strong-typed properties to take advantage of this.  However, if you want to have the strong typed properties as well, the best thing to do would be to create a table in the DDT that looks the way that you want it to look and map your BO to that table (just to get your strong-typed properties).  Obviously you would never deploy that DDT project, it would be used solely for mapping the properties on your BO.