Сведение к минимуму влияния на код миграции в хранилище BLOB-объектов Azure.

Я пытаюсь перенести довольно сложное приложение в Windows Azure. Как в рабочей роли, так и в веб-роли во многих случаях приложение сохраняет файлы в локальной файловой системе.

Вот пример:

string thumbnailFileName = System.IO.Path.GetDirectoryName(fileName) + "\\" + "bthumb_" + System.IO.Path.GetFileName(fileName);

thumbnail.Save(thumbnailFileName);

и еще пример:

 using (System.IO.StreamWriter file = System.IO.File.AppendText(GetCurrentLogFilePath()))
   {
     string logEntry = String.Format("\r\n{0} - {1}: {2}", DateTime.Now.ToString("[email protected]"), type.ToString(), message);
     file.Write(logEntry);

     file.Close();
   }

В этих примерах мы сохраняем изображения и файлы журналов в местах, указанных в файле app.config. Вот пример:

<add key="ImageFileDirectory" value="C:\temp\foo\root\auth\inventorypictures"/>

Я хотел бы внести как можно меньше изменений в код для поддержки хранилища BLOB-объектов Azure на случай, если мы когда-нибудь решим вернуться к более традиционной среде размещения, и в более общем плане уменьшить вероятность возникновения непреднамеренных проблем.

Основываясь на этом сообщении, я решил, что Azure Drive - не лучший способ идти.

Может ли кто-нибудь направить меня в правильном направлении (в идеале с примером)? Лучшим решением, на мой взгляд, было бы то, которое требует только изменения моего файла конфигурации. Но я предполагаю, что это не реально.


azure c# asp.net azure-storage-blobs
person hughesdan    schedule 21.07.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Действительно, вы хотите использовать хранилище BLOB-объектов Azure для сохранения файлов.

Что касается вашего вопроса о кодировании, рассмотрите возможность создания интерфейса, назовите его IFileStore:

public interface IFileStore
{
   void Save(string filePath, byte [] contents);
   byte [] Read(string filePath);
}

Затем вы создаете 2 класса поставщиков: один для файловой системы и один для хранилища BLOB-объектов Azure.

Поставщик файловой системы может реализовать функцию сохранения следующим образом:

    public void Save(string filePath, byte [] content)
    {
        File.WriteAllBytes(filePath, content);
    }

    public byte [] Read(string filePath)
    {
        return File.ReadAllBytes(filePath);
    }

Что касается поставщика больших двоичных объектов Azure, вам придется получить путь к хранилищу на основе переданного вам пути к файлу.

person Philipp Schmid    schedule 21.07.2011

arrow_upward
2
arrow_downward

В целом

Для вашего хранилища я бы рекомендовал использовать хранилище BLOB-объектов и таблиц — это позволяет нескольким экземплярам одновременно обращаться к хранилищу. Если вы хотите помочь сделать код переносимым, я бы рекомендовал абстрагировать ваш код от интерфейсов/API (см. ответ @Philpp).

e.g.

  • для вашего примера файла журнала лучше всего использовать хранилище таблиц
  • для ваших файлов изображений лучше всего использовать хранилище BLOB-объектов

Если вы действительно хотите использовать AzureDrive

Я бы рекомендовал использовать AzureDrive только в том случае, если вы собираетесь развернуть только один экземпляр своей роли, иначе вы столкнетесь с проблемами с совместным использованием файлов в нескольких экземплярах (и помните, что только 1 экземпляр может быть подключен с доступом для записи в любой момент). время)

Если вы работаете с одним экземпляром и храните только временные файлы и файлы журнала, вы также можете рассмотреть возможность использования локального хранилища вместо лазурного диска — это намного проще и дешевле в использовании, чем хранилище BLOB-объектов. например Одна из возможных специализированных альтернатив для вашего примера файла журнала заключается в том, что вы можете рассмотреть возможность использования локального хранилища вместе с загрузкой этого локального хранилища в хранилище BLOB-объектов, контролируемой службой диагностики Azure.

person Stuart    schedule 21.07.2011