Today we continue the discussion  on DBPowder. We noted earlier the process involved in the code generation, specifically given a conceptual model, how to map relational and object model. When EER is modeled using a directed graph, the starting entity is called the pivot entity. Connectivity on the edge is defined along with that of the corresponding relationship.Hierarchy is represented by directional edges from parent entity to child entity. When representing relationship, if there are attributes to the relationship, then they belong to the connected node to which the connectivity is many.If there are more than one path from the starting point to E, E has to fill all the conditions that correspond to the incoming edges. If this is not preferable, ObjectView can reduce the number of incoming edges by introducing another corresponded node and modifying one of the paths to use this node.  When grouping of nodes within a sub-graph, we form with those where the connectivity of the corresponding relationship is one. ObjectView arranges the class definitions generated from the grouped node  using the keywords structured, literal and interface. The structured literal is defined as a fixed number of  literals and the interface is defined as the abstract behavior of an object type. A structured literal can be used as a user defined literal. The interface is independent of the directed graph and applied to the group node.Multiple interfaces are possible for a grouped node in which case all the operations definitions are defined in the corresponding class.
In the example we took earlier with users and hosts, the application logic has to start from the user and hence the pivot entity is chosen. the node register and host are grouped.  The generated classes are user oriented. It's also possible to use host as pivot entity, in which case the sub-classes of the user are not required.
By using different ObjectView pivot entity, we can form the attributes from the grouped node. A practical generation of source code and their structure would involve code generation that corresponds to active records that has attribute values, setters/getters methods for data classes, and persistent classes for the wrappers of the data wrapper classes. Together with the active record and the logic classes, data persistence can proceed with the application codes defined by the developer and the call persistence methods on the session class that translate to SQL DDL. Developers of .Net framework can quickly associate these pieces of generated code to the templates defined from say the EDM.