设想一下,你有一个包含很多相似元素或者至少有很多相似属性的XML文档。通常这些项目都很具体。
如果当你设计XML文档时,对每一个项目都使用了不同的方法来描述,一旦日后你用不同的方法来读取元素,你就会觉得要区分开它们实在是太难了。
不一致的文法结构会使得用户无法记住你的XML文档结构,或者需要经常查阅XML文档,这些情况都会在处理XML文档时引发不可预知的问题。
假如你可以用任意方式来描述你的XML数据,那么下面几点符合一致性设计原则的规则会对你的设计有很大益处。
和其他的设计模式一样,没有一个成文的规定说什么时候或者怎样才能使用一致性设计原则。相反,一致性设计原则只是一种将问题抽象化的、草图似的解决方案。你的工作就是使用这个设计原则来解决具体的XML文档设计问题。
一致性设计原则使用一个叫“一致性”的概念来帮助你将XML文档设计的更直观。例如,CD播放器、磁带播放器、以及DVD播放器都有同样的基本控制方式――播放、停止、快进、快退、暂停以及弹出。这并不是偶然的。一致性设计原则的特点就是当用户一旦知道了分类规则就会对产品一目了然。下面我们举个例子来说明怎么把一致性设计原则应用到XML文档中。
首先我们从一个问题XML文档开始。列表A显示了一个订单的一部分内容――客户的两个地址。第一个地址是送货地址,包含两个地址行元素。第二个使用了一个特殊的地址元素用来描述送货地址的信息;它把街道门牌号和街道名字分开作为两个元素,同样也把城市、区、邮编都分开了。
Listing A: badorder.xml
<Order>
<Customer>
<ShippingAddress>
<AddressLine1>900 N. Michigan</AddressLine1>
<AddressLine2>Chicago, IL 60614</AddressLine2>
</ShippingAddress>
<Address type="billing">
<StreetNo>900</StreetNo>
<StreetName>N. Michigan</StreetName>
<City>Chicago</City>
<State>IL</State>
<Zip>60614</Zip>
</Address>
</Customer>
</Order>
可能很快你就能意识到这是个很烂的设计方法,并且可以通过一致性设计原则来修改它。我们可以利用一致性的原理将两类地址中类似的信息进行一致化处理,使它看上去更好理解。
鉴于第二个分类结构更合理,我们就选择用第二个地址信息分类作为标准。然后我们修改了第一个地址信息,使它与第二个地址信息看上去结构保持一致。列表B是我们利用一致性设计原则进行处理之后代码。
Listing B: goodorder.xml
<Order>
<Customer>
<Address type="shipping">
<StreetNo>900</StreetNo>
<StreetName>N. Michigan</StreetName>
<City>Chicago</City>
<State>IL</State>
<Zip>60614</Zip>
</Address>
<Address type="billing">
<StreetNo>900</StreetNo>
<StreetName>N. Michigan</StreetName>
<City>Chicago</City>
<State>IL</State>
<Zip>60614</Zip>
</Address>
</Customer>
</Order>
本文作者Brian Schaffner是富士通咨询公司的副主任。他为富士通的技术咨询公司提供架构、设计和开发支持。