Обеспечение электричеством клиентского кэширования WCF?

Это то, что меня заинтересовало, так как у меня есть требование для реализации флагов / переключателей функций в продукте, над которым я работаю. Я исследовал эту область в течение прошлой недели, и я поделюсь своими выводами и мыслями (я не утверждаю, что они являются наилучшей практикой в ​​любом случае). Эти выводы и мысли будут в значительной степени основаны на ASP.Net Zero и ASP.Net Boilerplate , так как я обнаружил, что они наиболее близки для примера реализации того, что я ищу.

Должны ли флаги объектов быть доступны клиентским приложениям?

blockquote>

Да и нет. Если вы создаете программное обеспечение как сервисный продукт (возможно, с несколькими арендаторами), то вам, скорее всего, понадобится какой-то интерфейс управления, где пользователи-администраторы могут управлять функциями (CRUD / Включить / Отключить). Это означает, что если вы создаете SPA, вам, очевидно, придется реализовать конечные точки в вашем API (конечно, с надлежащей защитой), которые ваш интерфейс может использовать для получения подробной информации о функциях и их текущем состоянии для целей редактирования. Это может выглядеть примерно так:

"features": [
    {
      "parentName": "string",
      "name": "string",
      "displayName": "string",
      "description": "string",
      "defaultValue": "string",
      "inputType": {
        "name": "string",
        "attributes": {
          "additionalProp1": {},
          "additionalProp2": {},
          "additionalProp3": {}
        }, 
      ....

Модель для функций, конечно, может варьироваться в зависимости от вашей проблемной области, но выше должна дать вам представление об общей модели для хранения определения функции.

Теперь, как вы можете видеть, в функции есть нечто большее, чем просто логический флаг, независимо от того, включен он или нет - у него могут быть атрибуты вокруг него. Это то, что для меня было совершенно неочевидным с самого начала, так как я думал о своей проблеме только в контексте довольно простых функций (true / false), где, как на самом деле, могут быть функции, которые намного сложнее. [1113 ]

Наконец, когда ваши пользователи будут просматривать ваше приложение, если вы визуализируете пользовательский интерфейс для арендатора, у которого включена функция EnhancedUI , вам необходимо знать, включена ли эта функция. В ASP.Net Zero это делается с помощью чего-то под названием IPermissionService, которое реализовано как на переднем, так и на заднем концах. В бэкэнде служба разрешений будет в основном проверять, разрешено ли пользователю доступ к некоторому ресурсу, что в контексте переключения функций означает проверку, включена ли функция для данного арендатора. Во внешнем интерфейсе (Angular) служба разрешений получает эти разрешения ( /api/services/app/Permission/GetAllPermissions):

{
  "items": [
    {
      "level": 0,
      "parentName": "string",
      "name": "string",
      "displayName": "string",
      "description": "string",
      "isGrantedByDefault": true
    }
  ]
}

Это может затем использоваться для создания какого-то рода RouteGuard, где, если что-то не включено или не разрешено вы можете соответствующим образом перенаправить, например, на страницу Upgrade your edition .

Надеюсь, это даст вам несколько идей для размышления.

8
задан 7 April 2009 в 18:32
поделиться

4 ответа

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

Ответ на этот вопрос может также помочь.

0
ответ дан 6 December 2019 в 02:26
поделиться

Если Вы хотите кэшироваться, не имея необходимость явно реализовывать его на каждом служебном вызове, рассматриваете Кэширующийся Обработчик в блоке приложений Инжекции политики. Можно отметить вызовы с атрибутом, и блок инжекции политики обработает кэширование для Вас.

http://msdn.microsoft.com/en-us/library/cc511757.aspx

-2
ответ дан 6 December 2019 в 02:26
поделиться

Я сделал это на днях с помощью универсальных методов расширения на клиенте службы WCF (DataServiceClient). Он использует действия и функции для передачи фактических вызовов ServiceClient. Окончательный синтаксис использования клиента немного прикольный (если вам не нравятся лямбды), но этот метод выполняет FaultException / Abort wrapping И кэширование:

public static class ProxyWrapper
{
    // start with a void wrapper, no parameters
    public static void Wrap(this DataServiceClient _svc, Action operation)
    {
        bool success = false;

        try
        {
            _svc.Open();
            operation.Invoke();
            _svc.Close();

            success = true;
        }
        finally
        {
            if (!success)
                _svc.Abort();
        }
    }

    // next, a void wrapper with one generic parameter
    public static void Wrap<T>(this DataServiceClient _svc, Action<T> operation, T p1)
    {
        bool success = false;

        try
        {
            _svc.Open();
            operation.Invoke(p1);
            _svc.Close();

            success = true;
        }
        finally
        {
            if (!success)
                _svc.Abort();
        }
    }

    // non-void wrappers also work, but take Func instead of Action
    public static TResult Wrap<T, TResult>(this DataServiceClient _svc, Func<T, TResult> operation, T p1)
    {
        TResult result = default(TResult);

        bool success = false;

        try
        {
            _svc.Open();
            result = operation.Invoke(p1);
            _svc.Close();

            success = true;
        }
        finally
        {
            if (!success)
                _svc.Abort();
        }

        return result;
    }
}

На стороне клиента мы должны вызывать их так:

    internal static DBUser GetUserData(User u)
    {
        DataServiceClient _svc = new DataServiceClient();

        Func<int, DBUser> fun = (x) => _svc.GetUserById(x);

        return _svc.Wrap<int, DBUser>(fun, u.UserId);
    }

Смотрите план здесь? Теперь, когда у нас есть общий набор оболочек для вызовов WCF, мы можем использовать ту же идею для внедрения некоторого кэширования. Здесь я использовал «низкотехнологичные» и просто начал разбрасывать строки для имени ключа кэша ... Вы можете сделать что-то более элегантное с отражением, без сомнения.

    public static TResult Cache<TResult>(this DataServiceClient _svc, string key, Func<TResult> operation)
    {
        TResult result = (TResult)HttpRuntime.Cache.Get(key);

        if (result != null)
            return result;

        bool success = false;

        try
        {
            _svc.Open();
            result = operation.Invoke();
            _svc.Close();

            success = true;
        }
        finally
        {
            if (!success)
                _svc.Abort();
        }

        HttpRuntime.Cache.Insert(key, result);

        return result;
    }

    // uncaching is just as easy
    public static void Uncache<T>(this DataServiceClient _svc, string key, Action<T> operation, T p1)
    {
        bool success = false;

        try
        {
            _svc.Open();
            operation.Invoke(p1);
            _svc.Close();

            success = true;
        }
        finally
        {
            if (!success)
                _svc.Abort();
        }

        HttpRuntime.Cache.Remove(key);
    }

Теперь просто вызовите Cache для чтения и Uncache на Create / Обновление / удаление:

    // note the parameterless lambda? this was the only tricky part.
    public static IEnumerable<DBUser> GetAllDBUsers()
    {
        DataServiceClient _svc = new DataServiceClient();

        Func<DBUser[]> fun = () => _svc.GetAllUsers();

        return _svc.Cache<DBUser[]>("AllUsers", fun);
    }

Мне нравится этот метод, потому что мне не нужно было ничего перекодировать на стороне сервера, только мои прокси-вызовы WCF (которые, по общему признанию, были немного хрупкими / вонючими, чтобы разбросаться повсюду).

Замените в своих собственных соглашениях прокси-сервера WCF и стандартных процедурах кэширования, и все готово. Сначала нужно создать много шаблонов-оберток, но я выбрал только два параметра, и это помогает всем моим операциям кэширования использовать одну сигнатуру функции (пока). Дайте мне знать, если это работает для вас или у вас есть какие-либо улучшения.

но я поднялся только до двух параметров, и это помогает всем моим операциям кэширования использовать одну сигнатуру функции (пока). Дайте мне знать, если это работает для вас или у вас есть какие-либо улучшения.

но я поднялся только до двух параметров, и это помогает всем моим операциям кэширования использовать одну сигнатуру функции (пока). Дайте мне знать, если это работает для вас или у вас есть какие-либо улучшения.

3
ответ дан 6 December 2019 в 02:26
поделиться

Подобно описанному выше решению, см. http://www.acorns.com.au/blog/ ? p = 85 (внедрение политики в службах WCF). Вы можете указать политику в соответствии с названием вашей службы.

0
ответ дан 6 December 2019 в 02:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: