2015-07-10 5 views
-3

Я в основном разработчик систем низкого уровня, поэтому я потерял все те инструменты высокого уровня, которые предлагает Azure и все эти слова.Какой сервис Microsoft Azure был бы лучшим для меня?

Итак, вот что я пытаюсь построить: Я создаю сервер, на котором есть часть обработки (возможно, с использованием Azure Batch) и часть хранилища (с использованием хранилищ, duh и DB). Я хотел бы, чтобы скрыть все это за интерфейсом, где клиентские приложения могут:

  • Вход в пользователях

  • Загрузить/Загрузить выбранные файлы

  • Управление их запущенную работы или начать некоторые новые

Клиентское приложение может быть на iPad, веб-браузере, ПК и т. д. ... Новые функции могут возникать или меняться на стороне сервера. Вот почему бы выбрать «серверный интерфейс» для стандартизации всех взаимодействий с клиентами, но я не знаю, какой инструмент Azure будет соответствовать моим потребностям в этом интерфейсе. Я не ищу что-то низкого уровня, как в создании моего собственного протокола и сервера, просто что-то, что просто сделало бы работу.

Приветствия

Léon Cantin

ответ

0

Я закончил выбор в пользу веб-API, который позволит мне «вызов» функции от сервера корыта HTTP ПРОТОКОЛ. URL-адрес - это «имя» функции, и данные либо сериализуются в теле или в URL-адресе. На самом деле простой и гибкий, он должен работать из коробки на любой платформе, которая может использовать HTTP или я мог бы найти библиотеку, которая позволяет мне это делать.

Мой тестовый код выглядит следующим образом:

Клиент:

private async Task SubmitJob() 
    { 

     JobModel job = new JobModel { ID = 42, name = "HelloJob", completion = 100.0f }; 

     try 
     { 
      HttpClient client = new HttpClient(); 
      HttpResponseMessage response = await client.PostAsJsonAsync<JobModel>("http://localhost:53122/Jobs/Submit", job); 
      if (response.IsSuccessStatusCode) 
       lblSuccess.Text = "Success!"; 
      else 
       lblSuccess.Text = "Failure!"; 

     } 
     catch (Exception ex) 
     { 
      string s = ex.ToString(); 
     } 
    } 

    private async Task GetJobs() 
    { 
     try 
     { 
      HttpClient client = new HttpClient(); 
      HttpResponseMessage response = await client.GetAsync("http://localhost:53122/Jobs/Info"); 
      if (response.IsSuccessStatusCode) 
      { 
       List<JobModel> jobList = await response.Content.ReadAsAsync<List<JobModel>>(); 
       txtConsole.Text = ""; 
       foreach(var job in jobList) 
       { 
        string line = "ID: " + job.ID + " Name: " + job.name + " completion: " + job.completion + "\r\n"; 
        txtConsole.Text += line; 
       } 
      } 
      else 
      { 
       txtConsole.Text = "Failure!"; 
      } 

     } 
     catch (Exception ex) 
     { 
      string s = ex.ToString(); 
     } 
    } 

Сервер:

 public async Task<IHttpActionResult> GetJobInfo(int jobId) 
    { 
     try 
     { 
      JobModel a = new JobModel { name = "jobA", ID = 102, completion = 100.0f }; 
      JobModel b = new JobModel { name = "jobB", ID = 104, completion = 42.0f }; 
      JobModel c = new JobModel { name = "jobC", ID = 106, completion = 0.0f }; 

      List<JobModel> result = new List<JobModel> { a, b, c }; 
      return Ok(result); 
     } 
     catch (Exception ex) 
     { 
      return InternalServerError(ex); 
     } 
    } 

    [HttpPost] 
    public async Task<IHttpActionResult> SubmitJob([FromBody] JobModel submitedJob) 
    { 

     return Ok(); 
    } 
2

Azure Mobile Services может быть хорошей подгонкой здесь. Поверхность заключается в том, что вы можете прототипировать ее быстро. В текущем портале вы можете использовать мобильные службы либо с бэкендом Node/JavaScript, либо с бэкэнд ASPAP WebAPI. Опция узла является самой быстрой/простой в реализации. Некоторые преимущества такого подхода:

  • Мобильный сервис автоматически получает создан с таблицей NoSQL стиле (думал, что это на самом деле хранится в SQL Azure БД под капотом) и выставляет REST конечные точки для CRUD, а также с помощью настраиваемых сценариев в JS для каждой конечной точки.
  • У мобильных служб есть собственные SDK для Windows (C# или WinJS), iOS (Obj-C или Swift), Android (Java) и HTML5 (JavaScript), поэтому вы можете легко подключить к ним любые ваши клиентские приложения.
  • Мобильный сервис также поддерживает фоновое задание, написанное на JavaScript. Это может быть использовано для вашей «обрабатывающей части» фона, хотя оценить ее можно без подробностей о том, что вы хотите сделать.
  • Вы также получаете встроенную поддержку для аутентификации (Twitter, FB, Google, MSA и AD) + Push-уведомления (WNS, GCM, APN, и т.д.)

В новом просмотра портала, услуги мобильной связи заменяются приложениями (в том числе мобильными), но бэкенд узла еще не поддерживается, поэтому моя рекомендация использовать Mobile Services вместо этого. Вы получаете больше контроля с бэкэндом ASP.NET WebAPI, но вам также нужно запрограммировать больше бэкэнда самостоятельно. Преимущество состоит в том, что вы можете хранить данные в любом месте (таблицы хранения, DocumentDB, SQL DB и т. Д.)

Для загрузки/выгрузки файлов вам необходимо использовать капли памяти Azure, и если вашему мобильному сервису необходимо каталогизировать файлы, связанные с каждым пользователем, вы можете просто сохранить полный путь «blob» для каждого файла в таблице Mobile Service.

Документы для Azure Mobile Services - наряду со многими учебниками - находятся на http://azure.microsoft.com/en-us/documentation/services/mobile-services/. У меня также есть 3 репозитория GitHub с образцом кода для Windows, iOS и Android, который интегрируется с Mobile Services по номеру https://github.com/search?q=user%3AActiveNick+AzureChatr и сообщение в блоге, которое объясняет их в http://www.ageofmobility.com/2014/10/06/azurechatr-building-a-cross-platform-chat-app-for-windows-ios-android/.

Надеюсь, это поможет.

Ник

+1

Спасибо за ваш ответ, я actualy condisidered мобильные приложения в какой-то момент и нашел ваш сайт. Я попробовал некоторые из примеров, которые у вас были, но не смог запустить их, так как у меня не было Windows 8. Казалось, что у меня были дополнительные функции, которые мне не нужны, и я был потерян во всем, плюс казалось, что он будет работать только для мобильных телефонов. Я ищу более общее решение, но исправьте меня, если я ошибаюсь. В настоящее время я рассматриваю веб-приложение API, которое предоставляет REST API, и, похоже, он довольно универсален для работы с хорошим набором устройств. –

+1

Mobile Services * - это самое простое решение и предоставляет REST API. Забудьте мои образцы, если вы найдете их слишком сложными. Просто попробуйте руководство по основным мобильным службам, например https://azure.microsoft.com/en-us/documentation/articles/mobile-services-ios-get-started/ для iOS или https://azure.microsoft.com/ru -us/documentation/articles/mobile-services-html-get-started/для Интернета. – ActiveNick

+1

Ум, я думаю, «простота» субъективна, потому что все дополнительные функции, которые добавляет приложение для мобильных приложений, не нужны из того, что я могу, и только смущают меня. Может быть, это потому, что я более низкий парень. Я соглашусь на веб-API, который предоставляет только то, что мне нужно, через REST-вызовы. Это почти как вызов функции, где имя находится в ссылке, и данные сериализуются со стандартом внутри тела HTTP-запроса. Это все, что мне нужно для создания мультиплатформенного интерфейса сервера. Может быть, я буду рассматривать Mobile App в будущем, так что спасибо! –