说一说我们工程中的“模型”

既然要说“模型”，那么我们先来看看我所要说的“模型”的定义，在维基百科上对“模型”有以下定义：

模型（Model） 用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“ Model ”有对数据直接访问的权力，例如对数据库的访问。“Model”不依赖“View”和“Controller”，也就是说， Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此 Model 上注册，从而，View 可以了解在数据 Model 上发生的改变。

有了以上的定义之后，可以清楚的知道模型就是“业务逻辑相关的数据以及对数据的处理方法（业务规则）”。在我们当前的工程中已基本实现了Model和View分离（ps: 有一些由于历史原因还没有分离出来），业务逻辑和数据模型分离到了名为ezbuyKit的framework中，对于业务逻辑部分可以做到很好的复用，同时也减少了代码出错率。

那么我现在就大概说一说我们的模型：

由于我们的业务是面向多个国家的，基本上每种业务都是和国家相关的，所以我们的模型封装了AreaService来提供业务中涉及到的服务给所有的国家，它是我们模型中很重要的一个类，所有和国家有关的业务规则都可通过AreaService来获取，比如网络请求的URL, 国家货币符号，货币规则，电话号码等。AreaService中定义有current变量，它代表了当前的国家，它由AreaServiceController来创建和切换。当用户切换了国家之后，该current变量也会变成对应国家的实例，通过current获取到的所有服务也一定会是对应国家服务。当需要增加国家时，只需要增加对应国家相应规则即可。

接下来说一说CustomerUser，它记录用户的一些信息（name, id, cookie, session, telephone, cart, message etc.），用户登录后会创建实例然后被AreaService来持有，通过AreaService持有的对象来获取一些用户的信息以及状态（cart, message, etc.），用户每次重新登录都会有新的user实例被创建，然后被持有。因而不会产生切换了，而有些用户信息还是上一个用户的，也不会因为切换了国家，而产生用户信息混乱。

然后再说一说我们的错误处理，在我们的模型中，我们定义一些有关业务的错误类型，当我们的模型中发生有关业务的错误时，就会抛出相关类型的错误，方便UI层面进行处理（弹出提示信息等）。

到了这里，已经对我们的模型有一个概述，剩下的部分都是一些和具体业务相关的模型，在这里就不一一细说了。