Альтернативный способ использования Azure Table Storage?

Question

Я бы хотел использовать для хранения таблиц сущность, подобную этой:

public class MyEntity
{
    public String Text { get; private set; }
    public Int32 SomeValue { get; private set; }

    public MyEntity(String text, Int32 someValue)
    {
        Text = text;
        SomeValue = someValue;
    }
}

Но это невозможно, потому что ATS нуждается в

1. Конструктор без параметров
2. Все объекты общественного и чтение / запись.
3. Наследовать от TableServiceEntity;

Первые два, это две вещи, которые я не хочу делать. Зачем мне хотеть, чтобы кто-нибудь мог изменить некоторые данные, которые должны быть только для чтения? или создавать объекты такого рода непоследовательным образом (для чего нужны .ctor?), или, что еще хуже, изменить PartitionKey или RowKey. Почему мы все еще ограничены этими требованиями десериализации?

Мне не нравится разрабатывать программное обеспечение таким образом, как я могу использовать библиотеку хранения таблиц таким образом, чтобы я мог сериализовать и десериализовать себя объекты? Я думаю, что пока объекты наследуются от TableServiceEntity, это не должно быть проблемой.

Пока мне нужно сохранить объект, но я не знаю, как его восстановить:

            Message m = new Message("message XXXXXXXXXXXXX");

            CloudTableClient tableClient = account.CreateCloudTableClient();
            tableClient.CreateTableIfNotExist("Messages");
            TableServiceContext tcontext = new TableServiceContext(account.TableEndpoint.AbsoluteUri, account.Credentials);

            var list = tableClient.ListTables().ToArray();

            tcontext.AddObject("Messages", m);
            tcontext.SaveChanges();

Есть ли способ избежать этих требований десериализации или получить необработанный объект?

Приветствие.

Answer 1

Если вы хотите использовать клиентскую библиотеку хранилища, тогда да, существуют ограничения на то, что вы можете и не можете делать со своими объектами, которые хотите сохранить.Пункт 1 правильный.Я бы расширил пункт 2, чтобы сказать: «Все свойства, которые вы хотите сохранить, должны быть открытыми и доступны для чтения / записи» (для целочисленных свойств вы можете избежать наличия свойств только для чтения, и они не будут пытаться их сохранить), но вы нена самом деле не нужно наследовать от TableServiceEntity.

TableServiceEntity - это просто очень легкий класс, имеющий свойства PartitionKey, RowKey, Timestamp и украшенный атрибутом DataServiceKey (посмотрите на Reflector).Все эти вещи вы можете сделать с классом, который вы создаете сами и не наследуете от TableServiceEntity (обратите внимание, что регистр этих свойств важен).

Если это все еще не дает вам достаточного контроля надкак вы строите свои классы, вы всегда можете игнорировать клиентскую библиотеку хранилища и просто напрямую использовать REST API .Это даст вам возможность выполнять поиск и десериализацию XML любым удобным для вас способом.Вы потеряете все приятное, что есть в использовании библиотеки, например, возможность создавать запросы в LINQ.

Answer 2

Ограничения, связанные с этой оболочкой ADO.NET для Table Storage, действительно несколько болезненны.Вы также можете принять Fat Entity подход, реализованный в Lokad.Cloud .Это даст вам гораздо больше гибкости в отношении сериализации ваших сущностей.

Answer 3

Только не используйте наследование.

Если вы хотите использовать свои собственные POCO, создайте свой класс так, как вы этого хотите, и создайте отдельный класс-обертку / контейнер tableEntity, который содержит pK и rK и содержит вашкласс как сериализованный байтовый массив.

Answer 4

Как насчет создания оболочек POCO во время выполнения с помощью System.Reflection.Emit http://blog.kloud.com.au/2012/09/30/a-better-dynamic-tableserviceentity/

Answer 5

Вы можете использовать композицию для достижения того, что вы хотите.Создайте свои объекты таблиц так, как вам нужно для хранения, и создайте свои POCO в качестве оболочек для тех, кто предоставляет API, который вы хотите видеть в остальной части кода своего приложения.Вы можете даже смешать некоторые интерфейсы для лучшего кода.