Дизайн API: Предоставьте XML или Объекты # 2 - PullRequest
2 голосов
/ 17 декабря 2008

Я недавно задал этот вопрос: Разоблачить 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? Это стоит целый набор объектов домена, которые потребуют бизнес-правил и проверки данных.

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

Ответы [ 6 ]

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

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

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

1 голос
/ 17 декабря 2008

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

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

1 голос
/ 17 декабря 2008

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

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

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

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

1 голос
/ 17 декабря 2008

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

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

Ваш веб-сервис будет обрабатывать все объекты Object <-> 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);

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

1 голос
/ 17 декабря 2008

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

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

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

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

Аргументы против этого, однако, продолжайте и продолжайте ..., чтобы назвать худших преступников:

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