Реализация JavaScript API-оболочки - PullRequest
5 голосов
/ 13 февраля 2012

Может ли кто-нибудь предложить шаблон, который можно использовать для написания JavaScript API wrapper , где нет общего кода между несколькими реализациями? Идея состоит в том, чтобы предоставить клиенту-потребителю единый API-интерфейс для одного из многих возможных API-интерфейсов, определенных во время выполнения. Вызовы API могут относиться к объектам / библиотекам, уже находящимся в среде приложения, или к вызовам веб-служб.

Следующие биты псевдокода - это два подхода, которые я рассмотрел:

Монолитный раствор

var apiWrapper = {
      init: function() {
          // *runtime* context of which API to call
          this.context = App.getContext(); 
      },
      getName: function() {
           switch(context) {
             case a:
               return a.getDeviceName() // real api call
             case b:
               return b.deviceName // real api call
             etc...
           }
      // More methods ...
    }
}

Плюсы : Может поддерживать согласованный API для потребителей библиотеки.

Минусы : приведет к созданию огромной монолитной библиотеки, которую трудно поддерживать.

Модульное решение

init.js

// set apiWrapper to the correct implementation determined at runtime
require([App.getContext()], function(api) {
  var apiWrapper = api;
});

module_a.js

// Implementation for API A
define(function() {
  var module = {
      getName: function() {
         return deviceA.getDeviceName();
       }
  };
  return module;
});

module_b.js

// Implementation for API B
define(function() {
  var module = {
      getName: function() {
         // could also potentially be a web service call
         return deviceB.getName;
       }
  };
  return module;
});

Плюсы : Больше обслуживания.

Минусы : разработчики должны позаботиться о том, чтобы API оставался согласованным. Не особо СУХОЙ.

Это может быть случай, когда что-то в духе Interface будет полезным, но, насколько я знаю, нет способа принудительно реализовать контракт в Js.

Существует ли наилучший практический подход для решения такой проблемы?

Ответы [ 3 ]

4 голосов
/ 13 февраля 2012

Какое совпадение, кто-то там делает то же, что и я!Недавно я углубился в шаблоны приложений JS и изучаю модульный шаблон.

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

было бы лучше перейти по модульному принципу:

  • главным образом, чтобы избежать зависимостей между двумя частями веб-сайта
  • , хотя одна может зависеть от другой, они "слабосвязанный ".
  • Для того, чтобы построить сайт, он должен работать без разрывов, когда вы разрываете его на части
  • Кроме того, вам нужно тестировать детали по отдельности, не используя ничего другого
  • легко заменяет базовые библиотеки (jQuery, dojo, mootools и т. Д.), Фактически не затрагивая существующие модули (поскольку вы создаете наш собственный API)
  • в случаях, когда вам нужно изменить / обновить свой API (или когдавы изменяете базовую библиотеку), вы только касаетесь «поддержки» API, а не переписываете код и не перекодируете части, которые его используют

вот ссылки, через которые я прошел (в основном vids), которыепередать, что такое модульный подход и зачем его использовать:

  • by nicholas zakas - как организовать API, библиотеки и модули
  • по дополниosmani - как и почему модули
  • от Michael Mahemoff - автоматическая регистрация событий модуля (крик / прослушивание)
3 голосов
/ 13 февраля 2012

Второй подход лучше, потому что он модульный, и вы или третье лицо можете легко расширить его, чтобы включить другие услуги.Точка «API остается непротиворечивым» не так верна, потому что при правильном модульном тестировании вы сохраняете непротиворечивость.

Второй подход также является доказательством будущего, потому что вы не знаете, какие невообразимые вещи, которые вам, возможно, придется сделать, чтобы реализоватьgetName для службы C, в этом случае лучше иметь отдельный module_c.js со всеми сложностями вместо спагетти-кода в монолитном одиночном модуле.

Потребность в реальном IMO с интерфейсом не так важна,достаточно документированного интерфейса с юнит-тестами.

2 голосов
/ 13 февраля 2012

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

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