Storage Client Library 2.0 - Why is the API not as intuitive to use as 1.7?

问题

I am migrating to using the new Storage Client Library for my Azure Table Storage.

Querying with the previous Storage Client Library 1.7 namespace:

var orders = serviceContext
                 .CreateQuery<Order>(tableName)
                 .AsTableServiceQuery<Order>()
                 .Where(e => e.PartitionKey == partitionKey && e.RowKey == rowKey)

Querying with the new Storage Client Library 2.0 classes:

string partitionKeyFilter = TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, partitionKey);
string rowKeyFilter = TableQuery.GenerateFilterCondition("RowKey", QueryComparisons.Equal, rowKey);
string combinedFilter = TableQuery.CombineFilters(partitionKeyFilter, TableOperators.And, rowKeyFilter);

var query = new TableQuery<Order>().Where(combinedFilter);
var orders = table.ExecuteQuery<Order>(query);

Please correct me if I'm wrong, but 1.7 is cleaner, uses strongly-typed entities, implements the IQueryable interface and utilizes the full power of LINQ. Version 2.0 makes me feel like I'm working with ADO.NET Datasets again.

Am I completely missing the plot here? I understand that there have been major performance improvements, but why does version 2.0 feel like such a downgrade as an API?

回答1:

Storage Client Library 2.0 still contains the legacy DataServices implementation in a different namespace. On the other hand, the new table implementation has shown significant performance improvements over the updated DataServices implementation and the previous versions of the SDK. Depending on the operation latencies have improved by between 25% and 75% while system resource utilization has also decreased significantly.

Please refer to Windows Azure Storage Client Library 2.0 Tables Deep Dive blog post for more information. As also mentioned in the blog post, you can still use the legacy DataServices implementation that has been migrated to Microsoft.WindowsAzure.Storage.Table.DataServices namespace if you prefer LINQ.

IQueryable support in the new Table Service Layer is currently in development. We don't have any more specific timeline details to share at this time.