Вы можете попробовать иметь очень общий интерфейс.Например:
interface ITableOperations<T, P, R>
where T : Azure.AzureTableEntity
{
string PartitionKey(P partitionKey);
string RowKey(R rowKey);
}
Тогда ваша реализация может быть:
public class ScheduledItem : ITableOperations<ScheduledPostEntity, Guid, DateTime>
{
public string PartitionKey(Guid userGuid)
{
return userGuid.ToString();
}
public string RowKey(DateTime dateScheduled)
{
return dateScheduled.ReverseTicks();
}
}
РЕДАКТИРОВАТЬ:
Глядя на некоторые из ваших комментариев, так как я изначальнонаписал этот ответ, вы могли бы прийти к нему под другим углом.PartitionKey и RowKey не будут меняться в вашем объекте после его создания, поэтому я бы почти исключил эти конкретные функции из этого класса и переместил бы его в конструкторы классов, которые наследуются от AzureTableEntity
.например,
public class ScheduledPostEntity : Azure.AzureTableEntity
{
private Guid _userGuid;
private DateTime _dateScheduled;
public ScheduledPostEntity()
{
// Needed for deserialisation from Azure Table Storage
}
public ScheduledPostEntity(Guid userGuid, DateTime dateScheduled)
{
_userGuid = userGuid;
_dateScheduled = dateScheduled;
}
public string PartitionKey
{
get { return _userGuid.ToString(); }
set { _userGuid = Guid.Parse(value); }
}
public string RowKey
{
get { return _dateScheduled.ReverseTicks(); }
set { _dateScheduled = value.FromReverseTicks(); }
}
// These are functions to avoid them being saved as additional properties
// in Azure Table Storage. Sometimes you can get away with them being
// read only properties, but it depends on the type.
public DateTime DateScheduled()
{
return _dateScheduled;
}
public Guid UserGuid()
{
return _userGuid;
}
}
Это имеет то преимущество, что всякий раз, когда вы создаете один из этих объектов, вы знаете минимальные требования для сохранения объекта.Это также мешает вам возиться с вещами, которые изменят ваш PK и RK.