Дизайн API:Предоставить доступ к XML или объектам #2

StackOverflow https://stackoverflow.com/questions/375548

Вопрос

Недавно я задал этот вопрос: Предоставлять доступ к XML или объектам - спасибо всем за ответы.

Один момент, который следует прояснить.

  • Доступ к API всегда будет осуществляться удаленно (т.е.как сервис), скорее всего, через веб-сервисы или WCF.

Я согласен, что теоретически строго типизированный API, предоставляющий объекты в качестве входных / выходных данных, является правильно так держать.Тем не менее, я чувствую, что все еще есть аргумент в пользу раскрытия XML.На мой взгляд, причинами использования XML являются:

  1. Бизнес-правила могут быть написаны бизнес-аналитиками в Schematron.
  2. Интерфейс слабо типизирован, но как только он вызывается, данные могут быть проверены на соответствие данным и бизнес-правилам.
  3. Внедрение сервиса будет проще.Не будет никакой необходимости создавать объектную модель домена.
  4. XML-схема уже определена (у нас есть словарь данных схемы).

  5. Использование технологии веб-сервисов означает, что API на основе XML не нужно будет изменять по мере добавления новых "типов" автомобилей, например 

    void AddNewCar( string newCarXml )    
string[] GetCars( /* some query conditions */ )

    Если бы мы использовали объектно-ориентированный API, то для добавления нового типа потребовался бы новый метод запроса, определяющий возможные производные типы, которые могли бы быть возвращены (см. расширение веб-сервисов).Обновление веб-службы подобным образом потребовало бы этих служб и ВСЕ существующие клиенты должны быть перестроены и перераспределены.

Что дает нам объектно-ориентированный API?Строго типизированный декларативный интерфейс.Он обеспечивает не больше абстракции, чем XML (XML сам по себе является абстракцией).Сколько стоит объектно-ориентированный API?Это стоит целого набора объектов домена, которым потребуются бизнес-правила и проверка данных.

Итак, в чем заключается мой вопрос?Назовите мне неоспоримую причину, по которой я должен использовать объекты.

Это было полезно?

Решение

  • Объекты могут работать лучше (здесь имеется в виду двоичная сериализация).
  • Объекты могут иметь более строгие проверки простого типа.
  • Объекты позволяют приблизить проверку и бизнес-правила к определению структуры данных.
  • Объекты по своей природе позволяют вам писать более простые бизнес-правила и проводить проверку, поскольку многое из этого встроено в само определение объекта.
  • Объекты также могут определять поведение.
  • .Net упрощает преобразование объектов в Xml и обратно с помощью сериализации, предоставляя объектам большинство тех же преимуществ, что и xml.

Другие советы

Если вы ищете аргументы в пользу XML (не то чтобы я особенно выступал за XML), то:

  • Раскрытие XML и предоставление XSD-кода говорит само за себя, когда речь заходит о данных.Вы можете передать все данные в этой форме, они самодокументируются и могут быть проверены достаточно просто.

  • Я могу написать кучу безопасного кода для своей базы данных или модели кода и я могу передавать данные автономным и безопасным способом другим бизнес-подразделениям, что требует минимальной дополнительной документации или объяснений.

  • Это настолько легко читается, что часто вы можете прочитать его так же легко, как вы могли бы прочитать документацию или комментарии к коду.

Аргументы против этого, однако, продолжаются и on...to назовите худших нарушителей:

  • Чересчур многословно.
  • Огромные накладные расходы на сеть.
  • Требуется понимание дополнительной технологии, возможно, без необходимости (?).
  • Чем сложнее вы что-то создаете, тем больше вероятность ошибок.

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

Как вы сказали, Xml можно использовать для определения замещающей объектной модели, но эта объектная модель должна проходить те же проверки во время выполнения, чтобы гарантировать надежность в определенной степени.Но это сопряжено с определенными конечными издержками во время выполнения.

Сказав это, все, что я хочу сказать, это то, что окончательный выбор остается за вами.Готовы ли вы отказаться от безопасности (а иногда и душевного спокойствия), обеспечиваемой "жесткой" объектной моделью, или вам будет удобнее с более гибкой, но способной выстрелить себе в ногу объектной моделью?XML требует большей дисциплины программиста и бдительности (что делает использование IMHO рутиной).

"Объектно-ориентированный" API не такой жесткий, как вы думаете, автоматически сгенерированные XML-схемы могут не выполнять то, что вы действительно хотите, чтобы они выполняли.Объектно-ориентированные API могут быть сделаны такими же гибкими, как API на основе XML, если они были хорошо разработаны.Динамический ввод текста тоже иногда может помочь.

Когда вы предоставляете обычный XML, всем вашим клиентам нужно будет написать код для генерации и анализа этого XML.Легкий на одних языках, ЛАВАШ на других.

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

Ваш веб-сервис будет обрабатывать весь объект<--> Содержимое XML внутри (для просмотра клиентом), вам не нужно будет беспокоиться о SOAP и всем таком.Вы сами определите свой интерфейс:

void addCar(Car newCar);
Car getCar(String make, String model, String year);
void removeCar(...);
List<Car> getAllCars();

что имеет большой смысл для ваших клиентов.Они берут ваш wsdl и генерируют свои клиентские библиотеки на Java, C #, PHP, Python и т.д.

Ничто не мешает вам добавлять:

int addCarXML(String carXML);
String getCarXML(int carID);

Но зачем добавлять два уровня веб-сервиса cruft - сначала wsdl, затем xsd для XML-схемы...

Посмотрите в Интернете статьи о дизайне, основанном на контрактах, на веб-сайте Spring есть хороший пример.Прямо сейчас я разрабатываю новый веб-сайт и выбрал подход, основанный на XML-схеме и использующий ее для разработки модели предметной области моего приложения.XML отлично подходит для отправки данных между разрозненными системами или даже уровнями ваших приложений.Он не зависит от языка программирования, и существует множество инструментов для редактирования, проектирования и реализации проектов на основе XML.

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

Вот еще одна случайная мысль - не используйте ни то, ни другое;-p Я думаю о других форматах обмена.В последнее время я проделал большую работу с буферами протокола - это предлагает использование по первому контракту (через определение ".proto"), но разработано с учетом безопасной расширяемости, т. е.вы можете создавать устройства для передачи неожиданных данных без поломок или потерь.К сожалению, спецификация основных буферов протокола фактически не включает наследование, но моя реализация (protobuf-net) регулирует это с помощью расширений.

Достаточно ли она зрелая, зависит от сценария - я просто подумал, что это может представлять интерес.Кроме того, он (protobuf-net) также подключается к WCF для удобства использования предварительно свернутого стека RPC;-p

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top