Кэширование ASP.NET на уровне доступа к данным (вопрос передового опыта) - PullRequest
1 голос
/ 21 января 2010

В настоящее время у меня есть модель данных LINQ 2 SQL и вспомогательный класс репозитория Passenger. Репозиторий выглядит следующим образом (из головы, поэтому код может содержать ошибки):

public class PassengerRepository 
{
    public static Passenger GetPassenger(int passengerId)
    {
        Passenger p = null;
        // Linq to sql code to retrieve passenger by passengerId and store in 'p'
        return p;
    }

    public static Passenger GetPassengerByUrl(string passengerUrl)
    {
        Passenger p = null
        // Linq to sql code to retrieve passenger by passengerUrl and store in 'p'
        return p;
    }
}

Кроме того, у меня есть класс PassengerController:

public class PassengerController
{

    public static Passenger GetPassenger(int passengerId)
    {
        if (Cache["Passenger_" + passengerId] != null)
            return (Passenger)Cache["Passenger_" + passengerId];

        Passenger p = null;
        p = PassengerRepository.GetPassenger(passengerId);

        Cache["Passenger_" + passengerId] = p;
        return p;
    }

    public static Passenger GetPassenger(string passengerUrl)
    {
        if (Cache["PassengerUrl_" + passengerUrl] != null)
            return (Passenger)Cache["PassengerUrl_" + passengerUrl];

        Passenger p = null;
        p = PassengerRepository.GetPassengerByUrl(passengerUrl);

        Cache["PassengerUrl_" + passengerUrl] = p;
        return p;
    }

}

PassengerId и PassengerUrl всегда уникальны для конкретного пассажира.

Моя проблема заключается в том, что я сохраняю дубликаты объекта Passenger при выборке по Id или Url, поскольку ключи кэша будут другими. Когда я получаю данные по Id, я сохраняю их в кеше с ключом, зависящим от PassengerId, и, следовательно, я не могу проверить, был ли этот объект Passenger уже сохранен для определенного URL. Это применяется другим способом, если при выборке по Url я не могу проверить в кэше, существует ли объект Passenger для определенного идентификатора. Мои вопросы:

  1. Каков наилучший способ хранения только одного экземпляра объекта Passenger в кэше, если выполняется выборка по URL или Id? Я подумал, может быть, создать оболочку для кэширования, а затем при извлечении с помощью Url, возможно, когда я получу данные Пассажира, я сохраню Пассажира в кеше по Id, а затем создаю новый ключ в кеше для Url и сохраню строковую переменную. с ключом для объекта Passenger Id. (то есть в ключе Url пассажира, я бы сохранил ссылку на ключ Id пассажира.)

  2. В дополнение к этому у меня все мои методы доступа к данным в классах Controller / Repository как статические - это эффективная и эффективная память?

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

Буду признателен за любой совет!

Ура, A.

Ответы [ 2 ]

0 голосов
/ 26 сентября 2012

Возвращаясь к этому вопросу через некоторое время. Я пришел к мысли, что это может быть довольно субъективным вопросом. Что бы это ни стоило, я фактически закончил тем, что хранил Пассажира ключом, сгенерированным из идентификатора Пассажира в кеше приложения, например Passenger_100. Затем я создал прокси-объект в ключе, который будет сгенерирован из Passenger URL (Passenger_myurl), который действует как ссылка на ключ Passenger_100.

0 голосов
/ 21 января 2010

Если вы дадите больше информации о вашей системе, мы можем быть более полезны. Например, сколько пассажиров у вас будет? Насколько мощный ваш сервер и т. Д. И т. Д.

Но с учетом информации я могу сказать:

  1. Вы можете кэшировать объекты Passenger в массиве после их поиска. Затем, когда вы хотите сделать еще один поиск, сначала выполните поиск в этом массиве. Если пассажир не найден в вашем массиве, перейдите в базу данных, получите информацию о пассажире, добавьте информацию о пассажире в ваш массив и верните информацию о найденном пассажире.

  2. На мой взгляд, этот путь кажется хорошим. Мы используем это также на некоторых сайтах среднего размера. Если кто-то предложит лучшие варианты, я тоже буду признателен.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...