API 设计：公开 XML 或对象 #2

我最近问了这个问题：公开 XML 或对象 https://stackoverflow.com/questions/368521/api-design-expose-xml-or-objects- 感谢大家的回复。

有一点需要澄清。

• API 始终可以远程访问（即作为服务），很可能通过 Web 服务或 WCF 进行访问。

我同意，理论上，将对象暴露为输入/输出的强类型 API 是right要走的路。然而，我认为对于公开 XML 仍然存在争议。我认为使用 XML 的原因是：

1. 业务规则可以由业务分析师在 Schematron 中编写。
2. 该接口是弱类型的，但一旦调用它，就可以根据数据和业务规则验证数据。
3. 该服务的实现将更加简单。不需要创建域对象模型。
4. XML 模式已经定义（我们有模式的数据字典）。

5. 使用 Web 服务技术意味着基于 XML 的 API 不需要随着新汽车“类型”的添加而改变，例如：

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

   如果我们使用基于对象的 API，那么添加新类型将需要一个新的查询方法来定义可能返回的派生类型（请参阅扩展网络服务 https://stackoverflow.com/questions/374253/extend-webservice-without-impacting-existing-clients-returning-derived-types-fr）。像这样更新网络服务需要此服务并且all现有客户端需要重建和重新部署。

基于对象的 API 给我们带来了什么？强类型声明式接口。它没有提供比 XML 更多的抽象（XML 本身就是一个抽象）。基于对象的 API 的成本是多少？它需要一整套领域对象，这些对象需要业务规则和数据验证。

那么，我的问题是什么？给我一个不可战胜、无可争议的理由，说明为什么我应该选择对象。

• 对象可以表现得更好（这里考虑二进制序列化）。
• 对象可以具有更强的简单类型验证。
• 对象允许您使验证和业务规则更接近数据结构定义。
• 对象本质上允许您编写更简单的业务规则和验证，因为其中大部分都嵌入在对象定义本身中。
• 对象还可以定义行为。
• .Net 使得通过序列化将对象转换为 Xml 以及再转换回来变得简单，为对象提供了与 xml 相同的大部分优点。