This project is read-only.


The focus of this namespace is to provide an API for the Entity Storage Service. Entities are value objects that represent something significant to an organization and maps this items properties to a data store. The Cloud Storage Entity Storage concept is that of infinitely large "tables" of data. Each row containing the data of one entity and each column representing one property of data in the Entity. However we've found that using that word in this context (the word in quotes in the last sentence) makes developers think of relational databases which is typically not what a Cloud Entity Storage is about. Therefor we are very careful about using that word in the CloudStorage.API and try to be clear about the fact that Entities are stored in Tables but they are not relational in nature. We would like to abolish the word "table" altogether but found that in the end this word is a familiar visualization for developers and is thus useful. In summary Entities are stored in the cloud in Tables but the tables are typically not relational.

This API is perhaps the weakest link in the CloudStorage.API chain - no sense in denying that. The reason is that our API for Entities is great for accessing Cloud Entity Storage through ADO.NET. Our Entity data manipulation interface for is extracted from the ADO.NET DataServiceContext. Remember this works on our machine and is useful for achieving our end. We'd love to get input on how this part of the API may evolve. Also ASO.NET was built for scenarios like this so it's not too bad. We just would have wanted the API not to be tilted toward a paricular kind of solution.

Another difficulty was that we wanted to be able to get an Entity Data Context for any kind of EntitySet. Given that we don't know the names of the entity properties at design time we opted for a more generic approach: We get our entity data context from a factory method and let the implementers solve how to return the right data context. The only way to be able to ask for a specific data context at design time is to know the entities before hand. Generics is not a very fun approach either because then you'd end up with entity properties name Entity1, Entity2 etc. The API deigns is better looking this way. A little bit of reflection will resolve the implementation (which are implementation details that are not part of the API).


Actually mostly the extracted interface from the ADO.NET DataServiceContext with the added functionality to be able to access any Entiy Data Set in the context in a general way.


The base (shared) contract for an entity.


Data Context for manipulating a Cloud Storage Entities.


Cloud Storage Tablesmanipulation.


Cloud Storage Table Storage contract.

Last edited Aug 19, 2009 at 1:57 PM by vonlochow, version 4


No comments yet.