0

I'm creating a custom EntityResolve, so that when I retrieve my azure table records, I will set a bunch of properties on the Business Object (TableEntity object) that are designed only to be used in my app and not persisted back to the Azure table. The properties on the Azure table are decorated with [IgnoreProperty] 

public delegate T EntityResolver<T>(string partitionKey, string rowKey, DateTimeOffset timestamp, IDictionary<string, EntityProperty> properties, string etag);

So, I'm creating the EntityResolver, and I will pass the delegate as a parameter in the ExecuteQuerySegmentedAsync method that will do the custom binding to the Table Entity.

However, I don't want to write code to custom resolve every single property to the TableEntity. I want to use all the default resolving functionality, but then add some additional code and business logic to set the other properties used for business logic.

In the resolver, is there anyway I can tap into the default or a kind of base resoling functionality, so that I do not have to re-write all that logic to do the same thing just because I want to add a few more pieces of code and logic to some new properties?

user1060500
  • 1,505
  • 1
  • 21
  • 40

1 Answers1

2

EntityResolver is used to customize client-side projection, where the code should all be customized. I haven't found any way provided for this method to get properties resolved automatically.

The resolving functionality can be achieved when we use query methods without resolver. For example: table.ExecuteQuerySegmented(query, continuationToken);

You can add properties to each entity after you get the query result. Like this:

var entities = new List<CustomEntity>();
foreach (CustomEntity c in table.ExecuteQuerySegmented(query, continuationToken))
{
    c.Data = 100;
    ......
    entities.Add(c);
}
Jerry Liu
  • 17,282
  • 4
  • 40
  • 61
  • Yeah, I couldn't find any other way either to use a custom EntityResolver and invoke the standard mechanism to resolve without re-writing code for each property. It's possible just to do that, but I didn't want the maintenance headache when other alternatives are available. My code already looks similar to yours, but I took a slightly different approach. I created a new class for the Azure table which inherits the existing class I have. I encapsulated the business logic I wanted for new fields into new properties of the new derived TableEntity class. – user1060500 Mar 21 '18 at 18:47
  • Then I just needed to decorate the new properties which contain my business logic with [IgnoreProperty] so that these fields don't get committed to the AzureTable and now can just truly be considered read only calculated fields. – user1060500 Mar 21 '18 at 18:49
  • 1
    Glad you've solve it and also thanks for your further explanation:-) – Jerry Liu Mar 22 '18 at 02:17
  • No problem! Thanks for your answer as well! – user1060500 Mar 22 '18 at 18:32