2

我最近问了这个问题：Expose XML or Objects - 感谢大家的回复。

有一点要澄清。

  • API 将始终被远程访问（即作为服务），最有可能通过 web 服务或 WCF。

我同意从理论上讲，将对象公开为输入/输出的强类型 API 是正确的方法。但是，我觉得公开 XML 仍有争议。在我看来，使用 XML 的原因是：

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

  5. 使用 Web 服务技术意味着基于 XML 的 API 不需要在添加新的汽车“类型”时进行更改，例如

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

    如果我们使用基于对象的 API，那么添加新类型将需要一个新的查询方法来定义可以返回的可能派生类型（请参阅扩展 Web 服务）。像这样更新 Web 服务需要重新构建和重新部署此服务和所有现有客户端。

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

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

4

6 回答 6

2
  • 对象可以执行得更好（这里考虑二进制序列化）。
  • 对象可以有更强的简单类型验证。
  • 对象允许您将验证和业务规则置于更接近数据结构定义的位置。
  • 对象本质上允许您编写更简单的业务规则和验证，因为其中大部分都嵌入在对象定义本身中。
  • 对象也可以定义行为。
  • .Net 使得通过序列化将对象转换为 XML 并再次返回变得简单，从而为对象提供了与 xml 相同的大部分好处。
于 2008-12-17T18:46:57.977 回答
1

如果您正在寻找支持 XML 的论据（不是我特别支持 XML），那么：

  • 当涉及到数据时，公开 XML 并提供 XSD 是不言自明的。您可以传递该表单中的所有数据，它是自我记录的，并且可以合理地简单地进行验证。

  • 我可以针对我的数据库或代码模型编写一堆安全代码，并且我可以以独立且安全的方式将数据发布给其他业务部门，而这些业务部门需要最少的进一步文档或解释。

  • 它非常容易阅读，以至于您通常可以像阅读文档或代码注释一样轻松地阅读它。

然而，反对它的论点还在继续……列举最严重的违规者：

  • 过于冗长。
  • 巨大的网络开销。
  • 需要了解额外的技术，也许是不必要的（？）。
  • 你做的东西越复杂，出错的机会就越大。
于 2008-12-17T18:46:22.130 回答
1

当您公开纯 XML 时，您的所有客户端都需要编写代码来生成和解析该 XML。在某些语言中很容易，在其他语言中是 PITA。

但大多数语言都有 Web 服务 API，可以使用 wsdl/xsd 并在几秒钟内生成完整的客户端库。当然，他们必须编写一个映射实用程序来从他们的内部模型映射到您的模型以与您交互，但这是意料之中的。

您的 Web 服务将在内部处理所有 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);

但是为什么要添加两个级别的 webservice cruft - 首先是 wsdl，然后是 XML 模式的 xsds...

于 2008-12-17T18:49:01.170 回答
1

强类型实际上任何类型都存在，唯一的原因是程序员不会犯任何愚蠢的错误（例如，将字符串传递给期望 int 的函数等）。最重要的是，这发生在编译时并且在运行时不花费任何成本，因此通过避免运行时检查（例如，正确的强制转换）和避免非托管代码在运行时的异常行为来生成高效的代码。

就像你说的，Xml 可以用来定义一个替换对象模型，但是这个对象模型需要在运行时进行相同的检查，以在一定程度上保证可靠性。但这有一定的有限运行时开销。

说了这么多，我想说的是，最终的选择是你的。您是否愿意放弃“刚性”对象模型所提供的安全性（有时是安心），或者您会更愿意使用更灵活但可以自己动手的对象模型？XML 需要更高的程序员纪律和警觉性（因此使用恕我直言是一件苦差事）。

“基于对象”的 API 并不像您想象的那样死板，自动生成的 XML 模式可能无法完成您真正希望它们执行的操作。如果设计得当，基于对象的 API 可以像基于 XML 的 API 一样灵活。动态类型有时也有帮助。

于 2008-12-17T18:49:29.487 回答
1

在网上查看有关 Contract-First Design 的文章，Spring 网站有一个很好的例子。我现在正在开发一个新的网站，并采取了从 XML Schema 开始并使用它来设计我的应用程序域模型的方法。XML 非常适合在不同系统甚至应用程序层之间发送数据。它与编程语言无关，并且有许多用于编辑、设计和实现基于 XML 的设计的工具。

它很冗长，但在事物的计划中，冗长是一个小麻烦。它可以创建大文件，只需压缩它。处理它有更多的开销，但我们开发人员总是用纯粹的性能来换取易用性、可维护性、可扩展性等。

于 2008-12-17T19:19:54.837 回答
1

这是另一个随机的想法 - 两者都不使用；-p 我正在考虑其他交换格式。我最近在协议缓冲区方面做了很多工作——这提供了合同优先使用（通过“.proto”定义），但在设计时考虑到了安全的可扩展性——即你可以设计一些东西来传递意外数据而不会破坏或损失。不幸的是，主要的协议缓冲区规范实际上并不包括继承，但我的实现（protobuf-net）通过扩展来填充它。

它是否足够成熟取决于场景 - 我只是认为它可能会引起人们的兴趣。顺便说一句，它（protobuf-net）还插入到 WCF 中，以方便预滚动的 RPC 堆栈；-p

于 2008-12-17T20:06:01.623 回答