• Классы BLOB-объектов
• Классы очереди
• Столовые классы
• Драйв классы
• Классы для сквозных задач, таких как обработка исключений и контроль доступа

Каждый из основных типов хранилищ (большие двоичные объекты, очереди, таблицы и диски) имеет то, что я называю классом точки входа, который инициализируется учетными данными учетной записи, а затем используется для создания дополнительных классов для доступа к отдельным элементам, таким как сообщения в очередях и большие двоичные объекты внутри. контейнеры. Для контейнеров больших двоичных объектов это класс CloudBlobClient , а для очередей — CloudQueueClient . Доступ к таблице осуществляется через CloudTableClient и TableServiceContext ; последний расширяет System.Data.Services.Client.DataServiceContext, который должен звонить в колокол для тех, кто работал с LINQ to SQL или Entity Framework. И, наконец, CloudDrive является точкой входа для монтирования Windows Azure Drive в локальной файловой системе, хорошо расположенной в сети или рабочей роли, которая его монтирует.

Хотя API-интерфейс клиента хранилища можно использовать непосредственно во всем коде, я бы порекомендовал инкапсулировать его в слой доступа к данным, который не только способствует тестируемости, но и предоставляет единую точку входа в хранилище Azure и, следовательно, единую точку для обработки. учетные данные, необходимые для доступа к этому хранилищу. В приложении Photo Mosaics эта роль проекта CloudDAL обсуждается далее.

Облако DAL

Класс TableAccessor имеет единственный открытый конструктор, требующий имя учетной записи и учетные данные для учетной записи хранения, за которую отвечает этот конкретный экземпляр TableAccessor . Сам класс по сути является прокси для CloudTableClient и ссылкой на TableServiceContext :

• _tableClient предоставляет точку входа для проверки существования и создания (при необходимости) необходимой таблицы Windows Azure, а также
• _context обеспечивает LINQ-доступ к двум таблицам, заданиям и состоянию , которые являются частью приложения Photo Mosaics. Каждая таблица также имеет объектное представление, реализованное через потомка класса TableServiceEntity , который был создан для представления схемы базовой таблицы Windows Azure; здесь эти классы-потомки являются StatusEntity и JobEntity .

Все методы, определенные в TableAccessor, используют один и тот же шаблон тестирования существования таблицы (через _tableClient ), а затем отправляют запрос (или обновляют) через _context и соответствующие классы TableServiceEntity . В следующем посте мы немного углубимся в реализацию TableAccessor (и некоторые его недостатки!).

BlobAccessor (в Blob.cs)

BlobAccessor аналогичным образом является прокси-сервером для ссылки CloudBlobClient и, как и TableAccessor, создается с использованием строки подключения, которая указывает учетную запись хранения Windows Azure и ее учетные данные. Имена методов достаточно понятны, но в будущем у меня также будет отдельный пост о деталях доступа к BLOB-объектам в приложении Photo Mosaics.

QueueAccessor (в Queue.cs и Messages.cs)

 

Класс QueueAccessor является наиболее сложным (и на рисунке выше даже не показаны связанные классы QueueMessage !). Как и BlobAccessor и TableAccessor , QueueAccessor является прокси-сервером для ссылки на CloudQueueClient для установления учетных данных учетной записи и управления доступом к отдельным очередям, требуемым приложением. 

Однако вы можете заметить, что QueueAccessor немного опирается на методы, и это потому, что функциональность основной очереди инкапсулирована в отдельный класс, ImageProcessingQueue и QueueAccessorсоздает статическую ссылку на экземпляры этого типа для представления каждой из четырех очередей приложений. Именно через ссылки ImageProcessingQueue (например, QueueAccessor.ImageRequestQueue ) веб-и рабочие роли читают и отправляют сообщения в каждую из четырех очередей, участвующих в приложении Photo Mosaics. Конечно, мы посмотрим, как это работает, в следующем посте. 

Со слоем CloudDAL у меня есть четко определенная точка входа в три типа хранилищ, используемых приложением, и мы могли бы на этом остановиться; однако при этом есть одна существенная проблема: аутентификация. Клиентскому приложению Windows Forms требуется доступ к BLOB-объектам и таблицам в хранилище Windows Azure, и если бы он сделал это путем непосредственного включения слоя CloudDAL, ему потребовался бы доступ к учетным данным учетной записи, чтобы создать экземпляр TableAccessor и ссылки BlobAccessor . Это может быть целесообразно, если вы ожидаете, что у каждого клиента будет своя собственная учетная запись хранения Windows Azure, и вы тщательно сохраняете учетные данные учетной записи локально (через защищенную конфигурацию в app.config).или какие-то другие средства). Но даже в этом случае, предоставляя клиентам прямой доступ к ключу учетной записи хранения, вы можете дать им веревку, чтобы они могли повеситься. Это равносильно предоставлению учетных данных конечного пользователя базе данных SQL Server традиционного клиент-серверного приложения с доступом администратора к загрузке! 

Если вы не жаждете перемены в карьере, такая реализация не в ваших интересах, и вместо этого вы захотите изолировать доступ к учетной записи хранения специально для тех элементов, которые необходимо перемещать назад и вперед к клиенту. Отличным средством изоляции здесь является веб-служба, специально реализованная как веб-роль WCF; это приводит нас к сервису StorageBroker .

Сервис StorageBroker

StorageBroker — это служба C # WCF, реализующая интерфейс IStorageBroker , и каждый метод интерфейса IStorageBroker в конечном итоге обслуживается CloudDAL (для большинства методов соответствие имен является очевидным). Вот, например, код для GetJobsForClient , который по существу оборачивает метод TableAccessor с тем же именем .

    public IEnumerable<JobEntry> GetJobsForClient(String clientRegistrationId)

    {

        try

        {

            String connString = new StorageBrokerInternal().
                              GetStorageConnectionStringForClient(clientRegistrationId);

            return new TableAccessor(connString).GetJobsForClient(clientRegistrationId);

        }

        catch (Exception e)

        {

            Trace.TraceError("Client: {0}{4}Exception: {1}{4}Message: {2}{4}Trace: {3}",

                clientRegistrationId,

                e.GetType(),

                e.Message,

                e.StackTrace,

                Environment.NewLine);

     

            throw new SystemException("Unable to retrieve jobs for client", e);

        }

    }

Поскольку это служба WCF, клиент Windows Forms может просто использовать прокси-ссылку на службу (Добавить ссылку на службу … в Visual Studio) для вызова метода по проводной связи, как показано в JobListWindow.vb ниже .   Это делается асинхронно, чтобы обеспечить лучший опыт конечного пользователя в свете внутренней задержки при доступе к ресурсам в облаке.

Private Sub JobListWindow_Load(sender As System.Object, e As System.EventArgs) 
   Handles MyBase.Load

     Dim client = New AzureStorageBroker.StorageBrokerClient()

     AddHandler client.GetJobsForClientCompleted, 

         Sub(s As Object, e2 As GetJobsForClientCompletedEventArgs)

            ' details elided 

         End Sub

client.GetJobsForClientAsync

(Me._uniqueUserId)

End Sub

Теперь, если вы внимательно посмотрите на методы в StorageBroker , вы заметите вызовы, подобные следующим:

    String connString = new 

    StorageBrokerInternal

    ().
        GetStorageConnectionStringForClient(clientRegistrationId);

Что с StorageBrokerInternal ? Давай выясним.

StorageBrokerInternal Service

Хотя служба StorageBrokerInternal может не совпадать с границами YAGNI , я включил ее по двум основным причинам:

Мне не нравилось копировать информацию о конфигурации для каждой из (трех) ролей в моей облачной службе . Вырезать и вставлять информацию из файла ServiceConfiguration.cscfg ( это не просто ракетостроение) (и это проще, чем использование пользовательского интерфейса свойств для каждой роли в Visual Studio), но это просто «неправильно» делать это.  StorageBrokerInternal позволяет указывать информацию о конфигурации один раз (через раздел конфигурации веб-роли AzureClientInterface ), а затем предоставлять доступ к любым другим ролям в облачном приложении через службу WCF, доступную на внутренней конечной точке HTTP — вы можете проверить мое сообщение в блоге на эта тема приключений также.

// instantiate storage accessors
blobAccessor = new BlobAccessor(
     StorageBroker.GetStorageConnectionStringForAccount(requestMsg.ImageUri));