The Unique Features of the Persistent Framework
  • Automatic Synchronization: When you make changes to an entity and that entity is related to another entity (Lets say Many of CustomerOrders to Customer), if you add new CustomerOrder in a separate context (Context here could mean, client thread (Standalone app, or web client) or/and between Open and Commit statements), that data, is automatically synchronized with other clients that are sharing the same persistent runtime.
  • Efficient on Demand Lazy Loading: Relationships like OneToMany, ManyToMany, are efficiently lazy loaded since this relationship fetches many entities. It is not wise to load these entities upfront, but with the lazy load feature, the entities are loaded when there is a demand for them. Example: A Customer has many Products that are in many CustomerOrders, we cannot fetch all of this at once when we are dealing with many objects. So, the automatic fetch is called when you call the get accessor on the list (Collection) that contains the objects, if you don’t call the get accessor, this objects won’t be called. Following is a better example to illustrate what I mean:

Customer customer = manager.LoadEntity (typeof(Customer), customerId);

The code above will not load the customer products until you do the following.


//This will not lazy load. It doesnt make any sense to lazy load anything yet here.

//But it does makes sense to lazy load here. which will only fetch what we required.

You can see the advantage that this gives to your application regarding performance issues. In-fact the lazy loading features of the persistent framework is described as very lazy, in the sense that object’s in a collection are not even loaded when you call the collection, objects are loaded one after the other from the database/Shared/transactional cache. That means if we have 100 orders related to a single customer, and we want to loop from 1 to 7, the persistent framework will not load all the 100 into the list at once, but will load them when they are demanded.
  • Efficient Caching Policy: The persistent framework supports both Shared and transactional Cache. Shared cache is global to executing thread, while transactional cache is visible within a transaction. The idea to maintain two different caches is because of concurrency reasons. We wouldn’t want two executing threads to change the same data at the same time would we? So a copy of a dirty entity is moved to the transactional cache while the global\shared cache still maintains the original copy of that object, until the persistent manager commits the transaction, then the transactional copy is merged with the global cache while we clear the one in the transactional cache. The caching policy adopted by the persistent framework is to reduce the overhead incurred when pulling state data every time.

*Support for Object Orientation Relationship: One of the aims of this API is to support Object orientation to the fullest. And, I have carefully built a fine grained Object Orientation support from ground – up. An example is inheritance among Entity classes. The following is an example:

• Customer inherits from BaseCustomer, so object of customer can override BaseCustomer ‘s members (If a Base class has its properties marked to be persistent, then the base class properties is query able. Only the base class property that is query able not the base class itself, because the class is not marked as Table).


The customer class does not contain the Id property, but the BaseCustomer class contains the Id which is marked as the primary key of the customer class. From the diagram above, the Base Customer class is not query able because it is not marked as Table, but the Id property is query able by the persistent framework, and all entities that inherit from this base class will automatically inherit the Id.

• Discriminatory Relationship: Persistent manager can allow a discriminatory relationship. In the sense that entities can be derived from the same table, but they will be discriminated by a value that will distinguish them from one and other. The following diagram depicts the type of a discriminator relationship :
  • Support for Generic and Non Generic Collections: The framework is built with CLR generics and non generics collection in mind. Automatic runtime collection instance is provided by the framework. As, if you have a relationship property as public virtual IList<CustomerOrders>, at runtime the framework knows which collection type to give to the interface IList<CustomerOrders>, as the framework is smart enough to do that.

  • Framework Built with CompositeKey in mind: The use of Composite Key is every where the framework makes extensive use of composite keys. Rules apply for composite keys, so you have to obey the rules of sequence. Follow the sequence of which the owner entity describes its composite key(s) at the class level definitions.

Support for Bi-Directional Relationships: The Framework support both side relationship in (One – To - One).

Last edited Sep 28, 2008 at 11:53 AM by ahmedsalako, version 4


No comments yet.