API Conception: Expose XML ou des objets # 2

Question

J'ai récemment posé cette question: Expose objets - Merci pour toutes les réponses

.

Un point à préciser.

• L'API sera toujours accessible à distance (par exemple en tant que service), très probablement via webservices ou WCF.

Je suis d'accord que, en théorie, une API fortement typée exposant des objets comme les entrées / sorties est le voie à suivre . Cependant, je pense qu'il ya encore un argument à faire pour exposer XML. Comme je vois les raisons d'utiliser XML sont:

1. Les règles métier peuvent être rédigés par des analystes d'affaires en Schematron.
2. L'interface est faiblement typé, mais dès qu'il est appelé les données peuvent être validées par rapport aux données et les règles commerciales.
3. La mise en œuvre du service sera plus simple. Il n'y aura pas besoin de créer un modèle d'objet de domaine.
4. Le schéma XML est déjà défini (nous avons un dictionnaire de données de schéma).

5. En utilisant la technologie de services Web signifie qu'une API basée sur XML ne sera pas nécessaire de changer comme neuf « types » voiture sont ajoutés, par exemple

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

   Si nous avons utilisé une API basée sur l'objet puis l'ajout d'un nouveau type nécessiterait une nouvelle méthode de requête définissant les types dérivés qui pourraient être renvoyés (voir étendant webservices extension des services Web ). Mise à jour du service Web comme celui-ci nécessiterait ce service et tous clients existants et à reconstruire redéployés.

Qu'est-ce une API basée sur les objets nous donner? Une interface déclarative fortement typé. Il ne fournit pas plus abstraction que XML (XML lui-même est une abstraction). Qu'est-ce que l'API à base d'objets coût? Il en coûte tout un ensemble d'objets de domaine qui ont besoin de règles de gestion et de validation des données.

Alors, quelle est ma question? Donnez-moi un non defeatble, la raison pour laquelle je indiscutables aller avec des objets.

Answer 1

• Les objets peuvent mieux performer (penser sérialisation binaire ici).
• Les objets peuvent être simples de type plus forts validations.
• Les objets vous permettent de mettre la validation et des règles commerciales plus étroites à la définition de la structure de données.
• objets par leur nature vous permettent d'écrire des règles de gestion et de validation plus simple, car une grande partie de qui est incorporé dans la définition de l'objet lui-même.
• Les objets peuvent également définir des comportements.
• .Net rend simple pour transformer des objets en Xml et retour via la sérialisation, donnant des objets la plupart des mêmes avantages que xml.

Answer 2

Si vous êtes à la recherche d'un argument en faveur de XML (pas que je suis particulièrement en faveur de XML) sont:

• L'exposition du XML et de fournir un XSD est explicite en matière de données. Vous pouvez passer toutes les données sous cette forme, il est auto-documenté et peut être raisonnablement validé simplement.

• Je peux écrire un tas de code en toute sécurité contre ma base de données ou d'un modèle de code et je peux libérer les données dans un autonome et de manière sûre à d'autres unités commerciales qui nécessite une documentation plus minimale ou une explication.

• Il est si facile de lire que vous pouvez souvent lire aussi facilement que vous pouvez lire les commentaires de la documentation ou le code.

Les arguments contre elle cependant, vont encore et ... de nommer les pires délinquants:

• Excessivement bavard.
• surcharge du réseau énorme.
• Exiger une compréhension d'une technologie supplémentaire, peut-être inutilement (?).
• vous plus complexe de faire quelque chose, la plus grande opportunité pour les erreurs il y a.

Answer 3

Le typage fort, en fait, tout de frappe du tout pour que la matière existe pour la seule raison que le programmeur ne fait pas d'erreurs stupides (par exemple. Le passage d'une chaîne à une fonction attendant un etc int). En plus de cela cela se produit dans le temps et la compilation ne coûte rien à l'exécution produisant ainsi un code efficace en évitant les contrôles d'exécution (par exemple. Pour moulages appropriés) et d'éviter un comportement anormal lors de l'exécution de code non managé.

Comme vous avez dit Xml peut être utilisé pour définir un modèle d'objet de remplacement, mais ce modèle d'objet doit subir les mêmes contrôles lors de l'exécution pour garantir la fiabilité dans une certaine mesure. Mais cela a une certaine surcharge d'exécution finie.

Cela dit tout ce que je veux dire est que le choix final est le vôtre. Êtes-vous prêt à abandonner la sécurité (et parfois la tranquillité d'esprit) offerte par un modèle d'objet « rigide » ou vous serez plus à l'aise avec un système plus souple, mais peut-shoot-vous-dans-le-pied modèle d'objet? XML exige une plus grande discipline de programmeur et de la vigilance (ce qui en fait une corvée à utiliser mon humble avis).

Le « objet basé sur » API est pas aussi rigide que vous pensez, les schémas XML générés automatiquement maynot être en train de faire ce que vous voulez vraiment qu'ils fassent. API à base d'objets peuvent être aussi flexible que l'API basée sur XML si elles ont été bien conçu. typage dynamique peut aider aussi parfois.

Answer 4

Lorsque vous exposiez XML ordinaire, tous vos clients auront besoin d'écrire du code pour générer et analyser que XML. Facile dans certaines langues, un PITA dans d'autres.

Mais la plupart des langues ont des API de services Web qui peuvent prendre wsdl / xsd et générer une bibliothèque client complète en quelques secondes. Bien sûr, ils doivent écrire un utilitaire de cartographie à la carte à partir de leur modèle interne à votre modèle d'interagir avec vous, mais c'est à prévoir.

Votre service Web traitera tous les objets <-> XML interne des choses (pour le point de vue du client), vous aurez pas besoin de vous soucier de SOAP et tout ça. Vous définissez votre interface:

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

qui fait beaucoup de sens à vos clients. Ils saisissent votre wsdl et de générer leurs bibliothèques clientes en Java, C #, PHP, Python, etc.

Il n'y a rien qui vous empêche d'ajouter:

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

Mais pourquoi ajouter deux niveaux de webservice cochonneries - d'abord le wsdl, puis les XSD pour le schéma XML ...

Answer 5

Jetez un coup d'oeil sur le web pour des articles sur contrat-First Design, le site web de Spring a un bon exemple. Je développe un nouveau site web en ce moment et ont pris l'approche en commençant par et XML Schema et l'utiliser pour concevoir mon application modèle de domaine. XML est un excellent pour envoyer des données entre des systèmes disparates ou même des couches de vos applications. Il est le langage de programmation agnostique et il existe de nombreux outils pour l'édition, la conception et la mise en œuvre des conceptions à base de XML.

Il est bavard, mais dans l'ordre des choses la verbosité est un ennui mineur. Il peut créer des fichiers volumineux, lui compresser. Il y a plus de frais généraux dans le traitement, mais nous, les développeurs sont toujours trading performance pure pour la facilité d'utilisation, la maintenabilité, l'extensibilité, etc.

Answer 6

Voici une autre pensée au hasard - ni utiliser ;-P Je pense à d'autres formats d'échange. Je l'ai fait beaucoup de travail ces derniers temps avec des tampons de protocole - cette offre l'utilisation du contrat-première (via une définition de « .proto »), mais il est conçu avec l'extensibilité en toute sécurité à l'esprit - à dire que vous pouvez concevoir des choses à passer à travers des données inattendues sans casser ou la perte. Malheureusement, les principaux tampons de protocole spécification ne comprend pas réellement l'héritage, mais ma mise en œuvre (protobuf-net) Cales ce via des extensions.

Que ce soit assez mature dépend du scénario - Je pensais juste que ce pourrait être intéressant. Soit dit en passant, il (protobuf-net) se branche également en WCF pour la commodité d'un empilement RPC préformé ;-P