<Chapter 2>2-2-1.用户偏好模式（The User Preferences Pattern）

在这个模块中我们要创建的应用是一个简单的钟。当一个用户访问这个网站时，这个应用会更具服务器的系统时间显示当前的时间。默认情况下，这个应用使用标准国际时间（UTC）时区显示当前时间。用户可以使用Google帐户登录和偏好设定来自定义时区。

这个应用演示了三个App Engine的特性：

・datastore，主要存储数据，一致的，可靠的，可扩展的。

・内存缓存，辅助存储，比datastore要快，但从长远看不一定时持久的。

・Google帐户，使用Google用户帐户系统来验证和识别用户的能力。

Google账户和大多数用户帐户系统一样工作。如果用户没有登录这个时钟应用，她看到一个一般视图带有默认设置（UTC时区）、登录和创建一个新用户的链接。如果这个用户选择去登录或注册，这个应用会引导她到一个由Google帐户管理的登录窗口。登录或创建一个帐户会再引导用户返回到这个应用。

当然，你可以实现你自己的帐户机制而不是使用Google帐户。你也可以利用App Engine中内置的对OpenID的支持来使用一个OpenID提供者（或用户选择的提供者）。使用Google帐户或OpenID有有点也有缺点——主要的有点就是你不需要实现你自己的帐户机制。如果应用的一个用户已经有了一个Google帐户，这个用户使用这个帐户来登录而不需要为你的应用创建一个新用户。

当用户已经登录后，如果访问这个应用，这个应用会加载用户的偏好数据并利用它来提供网页。应用通过两步取回偏好数据。首先，它会从快速辅助存储（内存缓存）中取数据。如果数据在内存缓存中不存在，应用尝试从主存储（datastore）中取回数据，如果成功的话，应用会将它放到内存缓存中为以后的请求查找。

这就意味着对于大多数请求，应用可以从内存缓存中取回用户的偏好，而不需要访问datastore。尽管从database中读数据也是很快的，但是从内存缓存中读会快得多而且避免了datastore的调用成本。每当用户访问一个网页时都要访问相同的数据时，这个差别就很大了。

我们的时钟应用有两个请求处理器。一个处理器显示当前的时间以及登录和退出的链接。当用户已8登录时，它也显示了一个网页表单来调整时区。当时区被提交时，第二个处理器处理时区。当用户提交了偏好表单时，应用保存变更并再引导浏览器返回这个主页面。

应用从它的服务器的系统时间取得当前时间。值得注意的是App Engine不保证应用的所有网络服务器的系统时钟时同步的。因为对于这个应用的两个请求可能会被不同的服务器处理，不同的请求可能看到不同的时钟。服务器时钟作为一个真实应用的时间数据源是不够一致的，但是对于这个例子已经足够了。

在下一个模块中，我们使用Python来实现这个应用。在"Developing a Java App"模块中我们做相同的事情。和之前一样，可以随意跳过不适合你的部分。