Sebastian,

>This is Sebastian E. Flucke - we know each other from the European Devcon (the guy with the implanted fox on his shoulder <vbg>)!

Ah, the infamous "fox-on-the-shoulder"!

>What is the normal way of usage of Data Access Objects (DAO) within a Business Object (BO) - is the normal way to have 1 DAO per BO or more than one?

Based on your question, I've added the following information to the Developer's Guide (it'll be in the upcoming version of Mere Mortals):

The business object and the data access objects contained within a data environment create a "bridge pattern". This architecture abstracts the "rubber meets the road" data access logic out of the business object and into a separate family of data access classes. This allows you to change your data access methodology without changing your business objects.

These different data access classes are automatically added to the data environment by means of the Business Object Builder. If you are accessing data by means of views, the Business Object Builder automatically adds an instance of the CDynamicViewCursor class to the data environment. If you are accessing data in free tables, or database tables, the CFreeTableCursor or CTableCursor classes are used instead. If you are accessing data by means of SQL pass through, the CSQLPassthrough data access class is used, and so on (Note: you can change which classes are added to the data environment by changing the corresponding records in the Abstract Factory’s Classes.dbf table). CDataAccessBase (located in CDataEnv.vcx) is an abstract base class from which all other data access classes are derived.

Here’s how the bridge pattern works—when you send a New() message to the business object, it passes this message on to the data access object which contains the code that actually creates a new record. When you send a Delete(), Save(), Requery() or any other data access message to the business object, it passes this message on to the data access object where the real work is done.

As mentioned previously, data environments can have one or more data access objects. How does the business object know which data access object it should send a message to? It sends the message to the "InitialSelectedAlias". In the Mere Mortals world, the InitialSelectedAlias corresponds to the first data access object that you have added to the data environment.

This means that when you design your business objects, typically the only cursor that is manipulated by the business object is the InitialSelectedAlias. Any additional data access objects are normally used to load read-only cursors. If you need to manipulate data in more than one cursor, create a separate business object instead. This actually promotes solid design. For example, the Invoices business object should only manipulate data in the invoices table. The Inventory business object should only manipulate data in the inventory table, and so on.

However, in some situations, it may make sense to have a single business object manipulate data in multiple cursors. The Framework's design allows provides an easy way to do this. You can dynamically change the business object's InitialSelectedAlias to point to another data access object by calling the business object's SetAlias() method. This method accepts a single parameter—the name of the alias to be set. After calling SetAlias(), the business object now sends all data access messages to the new InitialSelectedAlias.

Take for example a business object that has two data access objects, each loading a different view—one named v_FirstView and the other called v_SecondView. Assuming v_FirstView is the InitialSelectedAlias (the first one you added to the data environment in the Business Object Builder), by default the business object will send all data access messages to the data access object associated with v_FirstView. If you want to change this and manipulate records in v_SecondView instead, you can call the business object’s SetAlias() method as follows:

MyBizObj.SetAlias("v_SecondView")

Now, any subsequent data access messages are sent to the data access object that is associated with v_SecondView.

Regards,