====== Overview of IBPP Structure ======

{{overview.jpg }} Here is the overall big picture of the relationships between the various IBPP objects. Don't mis-read this graph: it is **not** a class derivation tree. The arrows show you the runtime dependencies of objects.

The blue rounded shapes are the IBPP 'Interfaces'. You call their corresponding ''[[guidelines#objects_instantiation_and_disposal|Factories]]'' to get instances of these objects. Except for ''[[Database]]'' and for ''[[Service]]'', each Factory call requires one or multiple references to other existing object instances. These dependencies are shown by the arrows. For instance, to instantiate an ''[[Events]]'' object, you need a ''Database'' object. Similarly, to get a ''[[Statement]]'' object, you need a ''Database'' and a ''[[Transaction]]''.

The ''Transaction'' object has a double arrow to the ''Database''. To instantiate a ''Transaction'' you indeed need a ''Database''. But you can later simultaneously attach your ''Transaction'' to multiple ''Database'' objects: a transaction context can span multiple database attachments.

The yellow rectangles are ordinary C++ classes. They are just datatypes defined by IBPP. Their dotted connections simply show you which interfaces they are related to. Indeed, ''[[Date]]'', ''[[Time]]'', ''[[Timestamp]]'' and ''[[DBKey]]'' are datatypes useful to exchange some non C++ basic values with SQL statements. ''[[User]]'' is a datatype related to the users management methods of the ''[[Service]]'' interface.

''[[Blob]]'' and ''[[Array]]'' are somewhat a special case. They are interfaces, and you instantiate them using their ''Factories'', which both require a ''Database'' and a ''Transaction'' for their context. Though, when instantiated they are used in relation with ''Statement'' to access special SQL values (blobs and arrays). This is why they are shown on the graph with a dotted line to ''Statement''.