Non-pochodne POCO i Azure Storage

Question

Czy możliwe jest posiadanie niepochodzonego POCO do przechowywania tabel Azure?

Innymi słowy, POCO, które nie wywodzi się z TableEntity lub implementuje ITableEntity?

Wydaje się krokiem wstecz, aby mieć model, który jest zależny od interfejsu lub klasy bazowej, ponieważ powoduje to przecieki referencyjne w górę w łańcuchu - nie mogę ustawić modelu w innym rzędzie bez konieczności bycia poinformowanym o Azure Storage dla interfejsu lub klasy bazowej!

Answer 1

Proszę spojrzeć na DynamicTableEntity (ctrl + f). Może służyć do wysyłania zapytań i wstawiania elementów.

Korzystając z tego typu, nie wprowadzisz żadnych zależności do swojego Modelu Domeny, jednak będziesz musiał samodzielnie przekonwertować POCO na DynamicTableEntity - proces ten można łatwo zautomatyzować, jeśli jednak chcesz zgłosić swoje POCO z niestandardowym interfejsem i zapisz mappera (po prostu potrzebujesz słownika właściwości + musisz wiedzieć, które są partycjami/RowKey).

Powodem, dla którego nie można po prostu zapisać dowolnego obiektu w magazynie pamięci masowej Azure, jest to, że musi wiedzieć, która właściwość działa jako klucz partycji i która jest kluczem wiersza. Plusem pracy z DynamicTableEntity na "niższym poziomie" jest możliwość tworzenia zapytań, które zwracają tylko podzbiór właściwości, co zmniejsza zużycie zasobów. To może, ale nie musi być korzystne w twoim przypadku.

Answer 2

Po pierwsze, nie ma innej alternatywy TableEntity i ITableEntity, który jest użycie DataServiceKey atrybut ozdobić swoją klasę, jak w poniższym przykładzie:

[DataServiceKey("PartitionKey", "RowKey")] 
public class MyEntity 
{ 
    public string PartitionKey {get; set;} 
    public string RowKey {get; set;} 
    public DateTime Timestamp {get; set;} 
    //other properties 
} 

jednak, że tak naprawdę nie rozwiąże problemu nie chcę przeciekać implementacji platformy Azure w klasie twojego modelu. W takim przypadku myślę, że warto przyjrzeć się użyciu implementacji opakowania, takiej jak LOKAD Fat Entities. Lokad poradzi sobie z serializacją/deserializacją twojego obiektu modelu w opakowaniu, które z kolei zostanie zapisane w pamięci tabeli. Jedną wadą dla Lokada jest to, że twoje obiekty stają się nieprzejrzyste w pamięci i nie można ich przeglądać z czymś takim jak Azure Storage Explorer.

Answer 3

Wystarczy popatrzeć na opakowaniu I wdrożone i umieścić w Nuget: https://www.nuget.org/packages/ObjectFlattenerRecomposer/

Jest również dodatkiem do Azure Storage SDK następnej wersji: https://github.com/Azure/azure-storage-net/pull/337/files

Opis:

zapewnia funkcjonalność do spłaszcz obiekty złożone w słowniku EntityProperty i funkcję, aby ponownie skompilować oryginalny obiekt złożony ze spłaszczonego słownika właściwości. Jednym z nich jest to, że API umożliwia pisanie dowolnego złożonego obiektu z zagnieżdżonymi właściwościami do magazynu Azure Table w spłaszczonej formie, co nie jest normalnie możliwe przy użyciu pakietu SDK Azure Storage Client.

Wersja 2.0 obsługuje teraz pisanie i odczytywanie właściwości typu IEnumerable, takich jak listy, tablice, słowniki do magazynu tabel Azure.

Blog: https://doguarslan.wordpress.com/2016/02/03/writing-complex-objects-to-azure-table-storage/

Zastosowanie: // zrównywanie obiekt i przekształcić go EntityProperty Słownik

słownik flattenedProperties = ObjectFlattenerRecomposer.Flatten (complexObject);

// Utwórz opcję DynamicTableEntity i ustaw jej PK i RK DynamicTableEntity dynamicTableEntity = new DynamicTableEntity (partitionKey, rowKey);

dynamicTableEntity.Properties = flattenedProperties;

// Wpisz DynammicTableEntity w Azure Storage Table użyciu SDK klienta

// Czytaj jednostkę powrotnej z AzureTableStorage jak DynamicTableEntity przy użyciu tego samego PK i RK podmiot DynamicTableEntity = [Czytaj z Azure używając PK i RK] ;

// Konwersja elementu DynamicTableEntity z powrotem na oryginalny obiekt złożony. Wyobraź sobie oryginalny complexObject należał do typu Order.

Kolejność zleceń = ObjectFlattenerRecomposer.ConvertBack (entity.Properties);