Right now, this is a placeholder for the documentation. This project will have little documentation of its own, as it seeks to provide parity with the Azure SDK (API Documentation). Currently, this project is in development, so this documentation should be viewed more as guidance for the final version than documentation of existing code at this point.

The API is broken into two main namespaces. The first is NModelsoft.Azure.Storage.Table. This contains two main interfaces, and two helper interfaces.

The two main interfaces are ICloudTable and ICloudTableClient. These provide the same public methods, properties, etc. as the CloudTable and CloudTableClient classes in the Azure SDK, with some slight differences as noted below.

Instead of TableQuerySegment<T>, an instance of the interface ITableQuerySegment<T> is returned from certain API calls. This is due to the Azure SDK choosing to make the constructor for TableQuerySegment<T> internal only. This seems to be an oversight, as the class is very simple (basically, a continuation token and a list of results). We use our own version to avoid the overhead of construction via reflection.

For similar reasons, we have a ITableResultSegment interface in lieu of TableResultSegment. All other classes are used from the Azure SDK, including TableResult, ITableEntity, DynamicTableEntity, and so on. This does mean that even the test doubles require version 2.0 of SDK to be installed; however, the emulator is not needed.

The intent is that where ever CloudTable and CloudTableClient are used in code, the interfaces can be used in their place, allowing the implementation to vary between the production adapter and the in memory mocks.

The second namespace is NModelsoft.Azure.Storage.Blob. This contains three main interfaces: ICloudBlobClient, ICloudBlobContainer and ICloudBlobDirectory. These provide the same public methods, properties, etc. as the CloudBlobClient, CloudBlobContainer and CloubBlobDirectory classes in the Azure SDK. Like the table API, these can be in used where those classes are used in code.

As with all mock services and test doubles, a dependency injection container greatly eases the use of this API. Of course, dependency injection can be manually done, so a framework like Unity or NInject is not required.

Currently, the documentation around permissions, context and how they affect calls is spotty; Much testing will be needed to insure behavioral parity with actual SDK. Also, the in memory mocks are completely synchronous; all asynchronous calls will behave as such.

Last edited Jul 8, 2013 at 10:24 PM by ndykman, version 2


No comments yet.