Централизация экземпляров CloudStorageAccount и TableServiceContext

В веб-роли ASP.NET MVC 3 я понял, что много пишу приведенный ниже код:

var account = 
    CloudStorageAccount.Parse(
        RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")
    );

var ctx = 
    account.CreateCloudTableClient().GetDataServiceContext();

Итак, я решил централизовать это для всего приложения ASP.NET MVC и создал следующий класс со статическими свойствами:

internal class WindowsAzureStorageContext {

    public static CloudStorageAccount StorageAccount { 

        get {
            return
                CloudStorageAccount.Parse(
                    RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")
                );
        }
    }

    public static TableServiceContext TableServiceCtx { 
        get {

            return
                StorageAccount.CreateCloudTableClient().GetDataServiceContext();
        } 
    }
}

И я использую это, как показано ниже, внутри моих контроллеров:

public class HomeController : Controller {

    private readonly TableServiceContext ctx = 
        WindowsAzureStorageContext.TableServiceCtx;

    public ViewResult Index() {

        var model = ctx.CreateQuery<TaskEntity>(Constants.TASKS_TABLE).
            Where(x => x.PartitionKey == string.Empty);

        return View(model);
    }

    public ViewResult Create() {
        return View();
    }

    [ActionName("Create")]
    [HttpPost, ValidateAntiForgeryToken]
    public ViewResult Create_post(TaskEntity taskEntity) {

        ctx.AddObject(Constants.TASKS_TABLE, new TaskEntity(taskEntity.Task));
        ctx.SaveChangesWithRetries();

        return RedirectToAction("Index");
    }
}

Я знаю, что это не подходит для модульного тестирования, и я должен обратиться к этому экземпляру TableServiceContext через интерфейс с помощью DI, но когда я это сделаю, я также рассматриваю возможность использования этого класса WindowsAzureStorageContext для получения экземпляра класса TableServiceContext.

Это хорошая практика? Не повредит ли это мне в какой-либо момент, потому что я использую один и тот же класс для всего жизненного цикла приложения?

Есть ли какой-нибудь известный шаблон для этого?


person tugberk    schedule 02.02.2012    source источник


Ответы (3)


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

person Tom    schedule 02.02.2012
comment
Спасибо! Причина, по которой я задал этот вопрос, заключается в том, что я не могу использовать все функции ключевого слова static. Я думал, не возникнут ли у меня проблемы, если я это сделаю. - person tugberk; 02.02.2012

Я думаю, вы можете использовать шаблон репозитория для общего контекста данных с общим интерфейсом поверх него. Не уверен, что это поможет, но вы можете сослаться на мой блог http://blogs.shaunxu.me/archive/2010/03/15/azure-ndash-part-5-ndash-repository-pattern-for-table-service.aspx

person Shaun Xu    schedule 03.02.2012

Я не верю, что между экземплярами контекста существует какое-либо общее состояние. При этом время транзакции для выполнения контроллера нетривиально. Чем дольше вы держитесь за контекст, тем выше вероятность возникновения конфликтов. Я обнаружил, что один из способов свести к минимуму конфликты и наложения — сделать цикл загрузки/изменения/сохранения как можно короче.

Эрик

person Erick T    schedule 04.02.2012