Question

我们正着手开发新的中间层服务，允许内部客户端系统在某些底层数据存储中创建，更新和查询记录。该服务将聚合多达3个单独的基础数据存储。出于这个问题的目的，假设：

数据存储＃1：专有XML数据库数据存储＃2：现成的关系数据库。
数据存储＃3：平面文件存储（以二进制形式存储的文件）。

客户端不会知道（也不关心）他们正在查询/更新哪个数据存储区。新服务将做出这个决定。我的问题是：我的API应该公开XML还是对象？例如。新API将有一个add方法。假设我们的系统是汽车存储系统，那么API的add方法可能如下所示：

AddNewCar( CarObject car )

或者，它看起来像这样：

AddNewCar( string carXml )

现在，即使第二个方法在入口处被弱化，XML也会立即针对模式进行验证。

新服务将用C＃编写（尚未确定哪个版本，但可能是3 / 3.5，WCF）。 API的客户端可以是C＃/ VBA / VB.Net / C ++ / Java）。

更多细节请告诉我。感谢

更新：请注意，API也将通过消息总线发布XML。例如。当添加新车时，将发布汽车XML，以便通知任何对新车感兴趣的人。

Answer 1

您不应公开XML，因为这会修复您的格式以及您可能面临的有关基础架构的任何未来决策。我总是会采用强类型路由来确保您正确地抽象实现，而不是使用它。

如果您采用XML路线并在开发过程中找出XML由于某种原因必须更改，那么更改API的所有用途以纠正该问题要比强类型更难API并隐藏了对象背后的XML细节。

Answer 2

当然，从最终用户 - 开发人员的角度来看，这种强大的方法将是最简单的，这是我更喜欢的。但是，如果最终所有内容都在幕后转换为Xml，或者您不确定客户会采取什么方法，我绝对建议您同时支持。

Answer 3

您应该使用对象创建API，并在需要时利用WCF提供XML API。

Answer 4

您应该使用Objects创建API，然后围绕该API创建Web服务接口（例如，对于Java，您将在您的接口上使用java2wsdl，然后使用wsdl2java来创建框架服务器端实现或客户端实现），我确信WCF中存在一种等价的方法，所有其他系统都可以查询。

由于您拥有多语言客户端，我认为Web服务是您的最佳选择，并且（忽略业务逻辑实现）只需几分钟的API工作。您可以将wsdl或xsd文件分发给所有客户端软件的开发人员，然后他们可以使用这些开发人员简单快速地与您的系统连接。

Answer 5

我会说暴露一个对象API。虽然不是出于上面另一篇文章中提到的原因 - 暴露XML导致更难以改变的固定格式。

可以说，强类型业务对象的API与XML一样难以改变 - 这两者都需要重新编译和重新构建。所以这不是你应该丢弃XML的原因。

原因 - IMNSHO - 是抽象层次的原因。在API级别，您正在讨论哪些业务对象或服务可以对其他业务对象执行哪些操作。因此，API必须以业务对象的方式进行讨论。

正如此处的另一篇文章所述，您始终可以使用XML表示形式支持业务对象。将业务对象和服务的XML表示保持在较低的抽象级别，API将为您提供XML的所有灵活性，同时允许您构建具有良好语义的更高级别的API。