ObjectLounge Quick Reference

Modeling Constraints

When you model your entities, there are certain constraints you have to know. Here are the most important ones:

• Entity classes must have a default (parameterless) constructor.
• They must have a field of type System.Guid for the entity's identity.
• They must be marked with the IdentityAttribute in which the name of the identity field is provided.
• The identity fields must be protected.
• All properties must be marked as virtual.
• Property accessors must be protected or public.

Dos and Donts

• Always assign new valid GUIDs to your Identity fields like this: _id = System.Guid.NewGuid();
• Do not set MasterRef properties directly; use the parent collection / property to change references.
• Having MasterRef properties is optional.
• Try to avoid accessing fields inside the entity classes; use properties instead (important for transactions).
• Never set the Identity fields on your own (after initialization) because they are managed automatically by the framework.

Composition and Aggregation Behavior

There are certains things you should know about compositions and aggregations:

• Composition is a strong relationship, also called "containment".
• Every entity class is composed by exactly one other entity class OR the context.
• If an entity is added to a composition, it will be in the data store when it is saved.
• If an entity is removed from a composition or never added to it after being constructed, it will not be in the data store when the context is saved.
• Both behaviors are automatically recursed to all children and grand-children.
• Both behaviors are re-eveluated if the state of an entity changes during runtime.
• Aggregations are weak links between entities.
• There can be as many aggregations in as many types as you want.
• Aggregations can only be established if the target is or will be in the data store.
• Thus, you cannot remove an entity if there's another entity pointing to it by an aggregation.

Transaction Behavior

Here is some important information on how transactions work in ObjectLounge:

• The isolation strategy of ObjectLounge is Read Committed.
• Concurrent write attempts are serialized by the framework.
• The transaction scope is bound to a managed thread.
• Reading data is always possible, no matter if there's a transaction running in the reading thread or not.
• Data can only be modified if there's a transaction running for the current thread.
• Committing the data makes changes visible to other transactions and persists the modifications in the store.
• You can either use the ObjectLounge Engine's ExecuteTransaction method to immediately execute a snippet of code and commit automatically or handle the the transaction yourself by calling the BeginTransaction method.