Azure с API для WPF и JavaScript
Я хочу создать следующий проект:
- Серверное приложение, размещенное на Azure — оно подключается к базе данных через платформу Entity и предоставляет API для всех, кто хочет подключиться (но с учетной записью, хранящейся в базе данных SQL).
- Приложение WPF — оно использует методы сервера, объекты и т. Д.
- Веб-приложение (php & javascript) — также использует серверные методы, объекты и т. д.
ВАЖНЫЙ У меня есть только подписка лазурного студента, и я хочу сохранить ее — о покупке чего-либо еще не может быть и речи, если только у нее нет веских аргументов.
Я решил, что для этого мне нужно создать REST Web API, потому что у меня нет другого выбора для подключения к серверу, кроме как через HTTPWebRequest (потому что я хочу иметь тот же API для WPF и веб-приложения).
Мой вопрос: лучшее решение существует?
Я думаю, что я могу создать другой API для настольного клиента, чем веб-приложение, но я не знаю, как это сделать. Не могли бы вы показать мне другой путь?
Почему я не хочу иметь это решение?
Причина проста. Для больших баз данных и медленного подключения к интернету загрузка целых данных займет несколько секунд. Насколько мне известно, в REST нет отложенной загрузки, поэтому поток моего приложения WPF, отвечающий за загрузку базы данных, зависнет на большой период времени.
Если мой вопрос слишком широкий, пожалуйста, оставьте комментарий, прежде чем поставить флажок.
Кроме того, любые советы, касающиеся моего проекта, приветствуются.
Решение
Различные API для рабочего стола и веб: это можно сделать достаточно легко. Предположим, у вас есть библиотека классов для хранения вашей бизнес-логики (предметная область). Создайте проект веб-API, который использует его, а затем создайте еще один проект веб-API отдельно, который также использует основные модели. При развертывании разверните каждый из них по отдельности в другой домен / поддомен (я не уверен, что вам потребуются дополнительные ресурсы Azure для этого, но примите во внимание api.desktop.myapp.com а также api.web.myapp.com… нет реальной технической причины, почему вы не можете сделать это таким образом, хотя по архитектурным соображениям я бы избегал этого (это действительно близко к тому, если не определенно является дублированием кода).
Одинаковый API для рабочего стола и веб: вы заявили, что думаете, что вам придется делать это по-разному для настольных компьютеров и Интернета, особенно из-за использования ресурсов на сервере. Я не согласен с этим и считаю, что вам следует внедрить некоторые стандартизированные ограничения скорости в ваш API. Обычно это достигается за счет того, что за один вызов можно вернуть только X ресурсов. Если первоначальный запрос запрашивает более X предела, API-интерфейс возвращает смещение / nextID, и клиент отправляет новый запрос, отмечая это смещение / nextID. Это означает, что у вас есть последующие звонки от клиента, чтобы получить все, что ему нужно, но дает вашему серверу возможность обрабатывать его небольшими порциями (например, проверка ограничений скорости, регулирование, балансировка нагрузки и т. Д.). Увидеть алгоритм с утечкой для реализации, которую я предпочитаю, сам: https://en.wikipedia.org/wiki/Leaky_bucket)
Другие решения
Других решений пока нет …
detector