Using the ObjectContainer in disconnected scenarios

This is the first part of some postings regarding the ObjectContainer and I would like to start with a bit of motivation.

Why does the ObjectContainer exist?
Because - we felt it is necessary to provide the same OpenAccess runtime environment in all tiers.

Ideally, the business logic should not be concerned if it is running in a connected world (where the database can be directly contacted) or in a remote/disconnected tier (where no database can be accessed). The business logic should just find the same API to compile against so that it could be running in both scenarios.

This is what the common interface IObjectContext for the IObjectScope and the ObjectContainer classes provides. Of course, not everything that you can find in the connected world is also available on the disconnected tier: An example for this are database queries, which are only possible when you are connected to a database server.
Fortunately there is also LINQ, which allows to use the same code to formulate queries against objects in memory as well as to fire the query against the real database.
But the ObjectContainer is not a pure stripped down version of the IObjectScope. It can be used for things which are not possible in the connected world of the IObjectScope. For example, you can serialize the ObjectContainer (with its content), send it around or make a duplicate. This is something that is not possible with the IObjectScope, as all the metadata and state information would need to be serialized too. But for the limited capabilities and database independent ObjectContainer this is perfectly possible. The serialization can even be done
in a fashion that an existing ObjectContainer can be updated with the serialized content of another one. Therefore round-trip processes are possible where modifications and new objects are send to the connected world which generates an update change set that can be applied to the original container.

Because the ObjectContainer lacks certain features like queries, it is relatively light-weight: a good fit for environments where computing resources are limited. I think of it as a briefcase that can hold a number of documents. The briefcase is a complementing thing to the office where the documents come from. You will find an organization and structure in a briefcase, but the office will certainly have more functionality (think queries and synchronization).

You can find the documentation for the ObjectContainer here along with some code examples.