XML 模式兼容性策略
我使用的应用程序使用大量 xml 接口进行集成和数据导入/导出。我们使用 JAXB 将这些接口映射到我们的域对象模型。我们经常面临的一个挑战是，在项目过程中面对新的需求，如何处理对这些接口进行更改的需要。
在理想的世界中，所有要求都是预先知道的。起草 xml 规范是为了反映这些要求，并且永远不会改变。但在现实世界中，影响接口的差距是在项目的整个生命周期中被发现的。其中一些更改的影响是良性的（例如引入新的非必填字段）。不过，对于其他类型的更改，可以选择以保留向后兼容性的“不干净”方式或不保留向后兼容性的“更干净”方法来实现它们。
例如，假设有一个新要求，需要在架构中出现“Field1”的所有位置添加“Field2”。由于“Field1”和“Field2”在功能/逻辑上进行分组，最自然的方法（我们将其称为“方法 1”）是将以下用法替换为：
<Field1></Field1>
方法 1 的优点
<GroupingName>
<Field1></Field1>
<Field2></Field2>
</GropuingName>
在于它易于实现并且维持。最大的缺点是破坏了接口。 Field1 的所有现有 XPath 都必须更改。另一种方法（“方法 2”）是在没有分组标签的情况下将 Field2 与 Field1 一起引入。
<Field1></Field1>
<Field2></Field2>
方法 2 保留了向后兼容性，但违反了“DRY”，并且不保证 Field2 出现在 Field1 出现的任何地方。
我的问题是，面对新需求，处理 xml 更改的行业标准/最佳实践是什么 是：
- 将方法 1 强加给客户（新需求 = 界面更改）
- 捂住鼻子，采用方法 2。
- 对代码库进行分支。在分支中实施方法 2，在主干中采用方法 1。 （在项目开始时不太可行）。
- 其他？
I work with an application that uses a large set of xml interfaces for integration and data import / export. We use JAXB to map from those interfaces to our domain object model. One challenge we frequently face is how to deal with the need to change to the these interfaces during the course of a project in the face of new requirements.
In the ideal world, all requirements are known up front. The xml specification would be drafted to reflect those requirements and then never changed. In the real world though, gaps that impact the interfaces are discovered throughout the lifecycle of the project. Some of these changes are benign in their impact (ex. introducing a new non-required field). For other types of changes though, there is an option to implement them in an "unclean" way that preserves backward compatibility or a "cleaner" method which does not.
For example, let's say that there is a new requirement to add 'Field2' everywhere that 'Field1' appears in the schema. Since 'Field1' and 'Field2' are functionally / logically grouped, the most natural approach (we'll call it "Approach 1") is to replace usages of:
<Field1></Field1>
with
<GroupingName>
<Field1></Field1>
<Field2></Field2>
</GropuingName>
The nice thing about Approach 1 is that it is easy to implement and maintain. The big disadvantage is that it has broken the interface. All existing XPath's to Field1 have to be changed. The alternative ("Approach 2") is to introduce Field2 alongside Field1 without the grouping tag.
<Field1></Field1>
<Field2></Field2>
Approach 2 preserves backward compatability but violates 'DRY' and does not guarantee that Field2 appears everywhere the Field1 does.
My question is, what are the industry standards / best-practices for handling xml changes in the face of new requirements Is it:
- Force apporach 1 on the customer (new requirements = interface changes)
- Hold your nose and take on approach 2.
- Branch the code base. Implement approach 2 in the branch and take on approach 1 in the main trunk. (Less workable at the beginning of the project).
- Other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
修改XSD以定义命名组；不是复杂类型：
并将“Field1”的每个元素声明替换为
这确保了“Field2”必须在“Field1”出现的任何地方出现在“Field1”之后。
如果出现是可选的，则设置。
Modify the XSD to define a named group; not a complex type:
and replace each element declaration of "Field1" with
this insures that "Field2" must occur following "Field1" everywhere "Field1" occurs.
Set if the occurance is optional.