我正在尝试构建一个为API构建XML响应的库。为了帮助说明我的问题,这里有两个示例API响应。第一个用于显示菜单,第二个用于显示文本。
<CiscoIPPhoneMenu>
<Title>Title text goes here</Title>
<Prompt>Prompt text goes here</Prompt>
<MenuItem>
<Name>The name of each menu item</Name>
<URL>The URL associated with the menu item</URL>
</MenuItem>
<SoftKeyItem>
<Name>Name of soft key</Name>
<URL>URL or URI of soft key</URL>
<Position>Position information of the soft key</Position>
</SoftKeyItem>
</CiscoIPPhoneMenu>
...
<CiscoIPPhoneText>
<Title>Title text goes here</Title>
<Prompt>The prompt text goes here</Prompt>
<Text>The text to be displayed as the message body goes here</Text>
<SoftKeyItem>
<Name>Name of soft key</Name>
<URL>URL or URI of soft key</URL>
<Position>Position information of the soft key</Position>
<SoftKeyItem>
</CiscoIPPhoneText>
好的,所以我的模块大纲看起来像这样:
class CiscoIPPhone(object):
def __init__(self, title=None, prompt=None):
self.title = title
self.prompt = prompt
class MenuItem(object):
def __init__(self, name, url):
self.name = name
self.url = url
class CiscoIPPhoneMenu(CiscoIPPhone):
def __init__(self, *args, **kwargs):
super(CiscoIPPhoneMenu, self).__init__(*args, **kwargs)
self.items = []
def add_menu(self, name, url):
self.items.append(MenuItem(name, url))
注意:为了便于阅读,我删除了这些类处理的验证和清理。
所以我的问题是:
答案 0 :(得分:1)
最不幸的是,我无法评论Python方面的事情。
就个人而言,我认为这种设计是非常可以接受的。
一个地方这些消息被序列化和反序列化。使用这些类的域代码创建一个,用必要的数据填充它,并将它(或其序列化表示)交给另一个组件。当实际序列化发生时,类本身会检查是否已设置所有必需数据。
这些类测试友好。您只需创建一条消息,填写一些值,然后检查XML序列化版本。测试模式 - 检查期望和实际输出。这些测试是整个协议的规范。
该设计适用于一个不错的流畅的API :
new CiscoIPPhoneMenu()
.withTitle("Title text goes here")
.withPrompt("Prompt text goes here")
...
出于参考目的,Martin Reddy在API design for C++中声明,对于协议或文件格式,要有一个组件可以转换为序列化表示或从序列化表示转换。我认为这正是这些课程的目的。
如果序列化表示发生变化(例如从XML格式变为二进制格式),您可以轻松地通过例如切换表示。提供接受格式的第二个ctor,或者您预期更改并引入SerializationFormat
枚举。
我可以很容易地想象一个python模块,它接受XML模式ComplexType并从中生成匹配的python类。一旦我尝试使用Altova XML Spy在C#中生成这些类;然而,这涉及引用运行时DLL,并使用另一个DLL 只是这似乎是太多的开销。这基本上是protobuf的工作方式,XML模式ComplexType在外部DSL中定义,序列化格式是二进制格式。