最近评论
正在载入评论列表...
我们可以解析显示在代码清单4-10中的类型所对应的XML数据，来生成客户端应用中的Garment对象。我们已经在第2章中看到如何做这件事，还将在第5章中看到它的几种变化，所以在这里不会讲述所有的细节。XML文档中包含了属性和标签内容。我们使用attribute属性和getNamedItem()函数读取属性的数据，并且使用firstChild和data属性读取标签的body文本，例如：
garment.description=descrTag.firstChild.data;
来解析一个XML片断，例如：
<description>Large tweedy hat looking
like an unappealing strawberry
</description>
注意一旦创建了garment，只需要调用构造函数，就会将其自动添加到所有garment的数组中。从数组中删除garment也是相当直接的：
function unregisterGarment(id){
garments[id]=null;
}
这样从全局注册表中删除了garment类型，但是不会连带地破坏任何已经创建的Garment实例。尽管如此，我们可以给Garment对象添加一个简单的验证测试：
Garment.prototype.isValid=function(){
return garments[this.id]!=null;
}
我们现在通过每个阶段细粒度的、容易处理的对象，为从数据库到客户端传播数据定义了一条清晰的路径。让我们重新回顾一下这些阶段。首先，从数据库创建了一个服务器端对象模型。在
接下来，使用模板系统来从对象模型生成XML数据流。最后，解析这个数据流从而在JavaScript层创建对象模型。我们现在必须手工解析，而在不远的将来可能会看到类似于ORM的映射库的出现。
当然，在管理应用中，我们可能还希望编辑这些数据，即修改JavaScript模型，然后就这些修改与服务器端模型进行通信。这将迫使我们面对存在两个领域模型副本的问题，它们可能失去同步。
在传统的Web应用中，所有的智能都位于服务器端，所以无论使用什么语言，模型也位于那里。在Ajax应用中，我们希望将智能分布在客户端和服务器端，以便客户端可以在向服务器端发送调用请求之前针对自身做出一些决定。如果客户端仅仅做出非常简单的决定，我们可以以随手编写少量代码的方式来处理，但是不可能充分利用智能客户端的长处，系统仍然会反应迟钝。如果我们授权客户端针对自身做出更加重要的决定，那么它就需要知道一些关于业务领域的事情。从这个角度上看，它确实需要一个领域模型。
我们无法除去服务器端的领域模型，因为一些资源只能在服务器端获得，例如持久层的数据库连接，访问遗留系统等等。客户端领域模型必须与服务器端的领域模型配合工作，它需要承担什么工作呢？第5章将更为全面地解释客户/服务器之间的交互，以及如何清晰地与一个分离为两部分的领域模型共同工作。
到目前为止，我们以相互隔绝的方式考察了模型、视图和控制器。本章最后的主题是重新将模型和视图融合在一起。
图书导读
