Gary's Blog

Psst, hey you! Yes you… can you keep a secret? You can? Good. Remember we said in our 2010 Roadmap

“The same goes for improvements to security: we shall be adding enough support for the security scenarios needed for XAF in the first part of the year, which will be fleshed out for other scenarios in the second.
…
Instance and field-level security will be made available in the second half of the year, building on the implementation in XPO from the first half.”

Well I have some news on that front. Coming in 2010.2 there will be some “undocumented features” to help support these required scenarios and I’ll let you in on the secret, if you promise not to tell the team that I told you.

We’ve added a new interface, IObjectLayer, the main implementer of this which is SimpleObjectLayer which serves as a bridge between the Session and the IDataLayer. To facilitate this, Session now has a new constructor which takes an implementer of IObjectLayer, in this case SimpleObjectLayer. The old constructor, which took an IDataLayer, still remains but this just creates a SimpleDataLayer for use with the Session, so we’ve maintained compatibility with your legacy code. Here’s a small example of what I’m talking about. Both the constructors in the example below, create a new UnitOfWork with a SimpleObjectLayer…

public void Example()
{
    //Get the data layer
    IDataLayer dataLayer = XpoDefault.GetDataLayer(connectionString, AutoCreateOption.DatabaseAndSchema);

    //Create a new unit of work, passing in a SimpleObjectLayer
    using (UnitOfWork uow = new UnitOfWork(new SimpleObjectLayer(dataLayer)))
    {
        //Do work with the objects
    }

    //SimpleObjectLayer created inside the constructor
    using (UnitOfWork uow = new UnitOfWork(dataLayer))
    {
        //Do work with objects
    }
}

Going forward, the changes we’ve made mean that the source of a Session need not only be a database, but can now be other sessions. To facilitate this we have created an Object, SessionObjectLayer, which will turn any UnitOfWork into a NestedUnitOfWork, like so…

using(UnitOfWork uow = new UnitOfWork(dataLayer)) {
    
    //Create a Person object
    Person person = new Person(uow);
    person.Name = "Thomas Anderson";
    person.Age = 27;
    
    //Save it
    uow.CommitChanges();
    
    //Create a nested UnitOfWork using the new SessionObjectLayer
    using(UnitOfWork nestedUow = new UnitOfWork(new SessionObjectLayer(uow))) {
        
        //Load the Person object by key in a nested UnitOfWork
        Person personNested = nestedUow.GetObjectByKey<Person>(person.Oid);
        
        //Change it
        personNested.Age = 35;
        
        //And save to the basic UnitOfWork
        nestedUow.CommitChanges();
    }

    //Check that the object has changed in the basic UnitOfWork
    System.Diagnostics.Debug.Assert(person.Age == 35);
    uow.CommitChanges();
}

The next step is to serialise objects between a basic and a NestedUnitOfWork. To do this, we created two classes SerializableObjectLayerClient and SerializableObjectLayer, which behave like they are two halves of a SessionObjectLayer object. Meaning that the data that is sent between them, via ISerializableObjectLayer, can be serialised. This means our previous example, becomes…

using(UnitOfWork uow = new UnitOfWork(dataLayer)) {
    
    //Create a Person object
    Person person = new Person(uow);
    person.Name = "Thomas Anderson";
    person.Age = 27;
    
    //Save it
    uow.CommitChanges();
    
    //Create a serialized ObjectLayer
    ISerializableObjectLayer sol = new SerializableObjectLayer(uow);
    
    //Create a client of serializable ObjectLayer
    IObjectLayer ol = new SerializableObjectLayerClient(sol);
    
    //Create a nested UnitOfWork
    using(UnitOfWork nestedUow = new UnitOfWork(ol)) {
            
        //Load the Person object by key in a nested UnitOfWork
        Person personNested = nestedUow.GetObjectByKey<Person>(person.Oid);
        
        //Change it
        personNested.Age = 35;
        
        //And save to the basic UnitOfWork
        nestedUow.CommitChanges();
    }

    //Check that the object has changed in the basic UnitOfWork
    System.Diagnostics.Debug.Assert(person.Age == 35);
    uow.CommitChanges();
}

Of course, the instance of SerializableObjectLayer can be anywhere, on another process, or even on another machine and you can access it via WCF, Remoting or any data transmission technology of your choice. This means that, at last, it is possible to build more complex N-tier systems using XPO!

It also enables a couple of different scenarios. Firstly, thin clients can push complex validation onto a server and simply load the processed objects. Secondly, it enables the long awaited field level and object instance security as the SessionObjectLayer object has a number of options that allow you to implement specific object processing – such as filtering – based on rules for loading and saving. Lastly, you can write a custom implementation of IObjectLayer which would allow you to write a wrapper for other ORMs.

So why’s this stuff going to be undocumented in 10.2? Well it’s because these changes are really there to support the upcoming rewrite of XAF’s security system. As we stated in comments to previous blog posts, this rewrite will not be completed in the 10.2 timeframe so we decided to leave these XPO features undocumented at this time. So remember, no telling the team that I spilled the beans.

Well that’s all for this post, until next time, happy XPOI’ing

UPDATE: XPO – 11.1 Sneak Peek - WCF services for IObjectLayer