1

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

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

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

AddNewCar( CarObject car )

或者，它可能看起来像这样：

AddNewCar( string carXml )

现在，即使第二个方法在入口处被弱类型化，XML 将立即根据模式进行验证，至少是。

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

任何更多细节请告诉我。谢谢

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

4

5 回答 5

2

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

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

于 2008-12-15T14:32:21.550 回答
1

当然，从最终用户开发人员的角度来看，严格类型的方法将是最简单的，这是我更喜欢的。但是，如果最终一切都在幕后转换为 Xml，或者您不确定您的客户将采用哪种方法，我绝对建议您同时支持这两种方法。

于 2008-12-15T14:29:18.623 回答
1

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

于 2008-12-15T14:32:26.340 回答
1

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

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

于 2008-12-15T15:11:28.477 回答
1

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

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

原因 - IMNSHO - 是抽象级别的原因。在 API 级别，您谈论的是哪些业务对象或服务可以对哪些其他业务对象执行哪些操作。因此，API 必须根据业务对象进行交谈。

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

于 2008-12-16T12:44:34.263 回答