When using an ORM one of the first questions users have is: But how is my data accessed?
OpenAccess uses a technique called Enhancement to augment the compiler generated code. It works like as if the compiler had weaved in some additional code - much like the AOP people are doing it. The added code allows to provide the application with the needed management, lazy loading and change tracking capabilities. Because the code is compiled, there is no need to use reflection and therefore guarantees you a speedy access to your data. Your database data just comes into the objects as their fields are accessed.
But what if you have the need to access your database data in a reflection like manner without compiled code to hold the values? Then you could either use System.Reflection or use the newly introduced PersistentMetaData type, which follows the System.ComponentModel approach. With the PersistentMetaData you get also other meta information like the names of the
identifying fields or whether the field is read-only. In future versions we will enrich this API even further, think table and column names...
Lets have a look how this works out:
static void PrintTheName(object pc)
{
IObjectScope scope = Database.GetContext(pc) as IObjectScope;
if (scope == null)
throw new Exception("Metadata only available when connected to a database");
IPersistentTypeDescriptor ptd = scope.PersistentMetaData
.GetPersistentTypeDescriptor(pc.GetType());
Console.WriteLine(ptd.GetProperties()["name"].GetValue(pc));
}
The first statement will get the object scope from which we can obtain the PersistentMetaData. This meta information is only available (at the moment) when working connected as it requires the mapping information to be present. In the next statement a custom type descriptor is obtained for the type of the given object. And in the last statement we obtain the current value from the associated property descriptor with the name "name".
Why is that such a big deal?
Because it allows you to write code, which does not need to be compiled against your persistent classes, or that is working over fields with the same name but from different persistent types or that first discovers the present persistent types and later uses them. This could be useful for report writers for example.
One even bigger reason will be made obvious by another post; stay tuned!