该篇为James Bright发布基于iPhone云体系的第一篇，详细的讲述了云体系中每一层的由来及每一层在体系中起到的作用。该体系从数据库的选取和数据存储程序的编写起，就开始了对安全性与速度的双重考虑。而在反复的测试后更是加入了Phone.Services层。
我们一直想让用户可以简单、快速的共享他们收藏的图片。事实上，产品最先发布的原身是Pinterest的一个版本，用于收集一个市场路线图。最初的网络版发布后我们就认识到，在上传图片的时候还存在一定的困难，所以我们一直在致力新方法的研究。我们首先在iPhone上进行了尝试，并希望在不久的将来能推出Android应用。因为开始时，我们只能把精力集中在一个方向。
我在之前的报告中提到过每层都是一个成本投资。事实上，最初我们没有“Phone.Services”这层。这是我们之后发现在手机中使用中间层来缓存数据可以大限度的提升性能。下面将概括的描述一下每一层的用途。
Data Layer
现在你可能认为我们将使用SQL Server作为我们主要的数据储存。但是我们使用的是BizSpark，微软出品的一个世界级项目，完全可以承担起后台数据库服务器的重任。没有广泛的Microsoft经验，我们也许回答不出为什么不选择SQL Server。在我们访问数据库过程中有99%都是通过存储程序实现的，只有三两个是通过数据库原生的SQL工具（没有这些网络上可以利用的，就没有了SQL注入攻击的可能）。我们认为数据库的价值只在于数据的储存。我们的存储程序非常短，而且他们之间是没有逻辑的。以后我将会在博客中公布一些我们的数据结构，你将会看到故意不规范的一些方面。
Bit.Services Layers
开始猛攻Collectibles之前，我们得多考虑其他一些方面。将包含立足一个合适的应用，FaceBook的游戏应用，最后再回到我们的出发点。但是之前还必须做出一些其他的测试，我们建立了“23bits.com，LLC”。正因为这个我们才把命名空间定为“Bit”。很友善、简短、便于输入而且引人注意，对吧？！
基本的Services Layer应该提供数据库的连接，可以对数据库进行任何操作并且可以为ASP.net层提供简单的实体类型。这些服务和其他的网络类型及iPhone应用程序相同。关于这点，将会在今后的讨论中给出更详细的解答。这里将会有12个左右的服务来保障安全、用户资料、收藏、论坛、社区及那些还没有启动的特色。服务之间的依赖性将通过使用Ninject被DI（Dependency Injection）管理。理论上这些为硬件提供支持的服务是可以独立划分的，在实力增长后我们也必将把他们分开。
Internet Bounday（ASP.net MVC3.5）
当下来说仍然是ASP.net MVC3，但是同样可以作为MVC4运行并且处理的无限接近于MVC4。我们将很快的升级然后将使用更多的方法使Web API技术变的更酷！同时它还响应了基础JSON的号召。随后，将会出一篇介绍我们是用什么样方法来保护我们系统的博客。虽然现在这个API接口的工作原理还只能用于iPhone，但是不久的将来这个API同样会在Android和Windows上出现。
Bit.ClientServices
当然，客户服务设计模式并不意味着你只能拥有一个客户端和一个服务。对于这种情况，通过iPhone的客户端我们还拥有一个依赖于我们后端服务器的服务。它将在iPhone上通过服务本地应用ClientServices层来促进通信。最需要关心的事就是如何不破坏iPhone的应用就可以实现对服务器的通话，即使在innerwebs低下的时候。然而它将会很好的完成这项使命。
Phone.Services
我们来到了最终层，这层是个很特殊的平台。这层是在一些实际测试后被加入，测试的结果发现，只需添加少量的缓存，手机性能就会呈戏剧性的提高。也许其中有一些东西Facebook应用是可以用到的。于是我们给Bit.ClientServices加了让它可以高速响应的缓存。当我们继续深挖Bit.ClientServices细节时还发现这个可移植层可以在Android和Windows手机应用上重利用。很轻量，主要用于ClientServices的调用。只需要知道自己能缓存什么和不能缓存什么，还要知道一下UI控制的特殊性。所以有了它你本地的Facebook应用将得到新的提升
