基於iPhone的雲體系 — 結構的形成

我們一直想讓使用者可以簡單、快速的共用他們收藏的圖片。 事實上，產品最先發佈的原身是Pinterest的一個版本，用於收集一個市場路線圖。 最初的網路版發佈後我們就認識到，在上傳圖片的時候還存在一定的困難，所以我們一直在致力新方法的研究。 我們首先在iPhone上進行了嘗試，並希望在不久的將來能推出Android應用。 因為開始時，我們只能把精力集中在一個方向。

將有一系列（3-5）文章講述iPhone應用是如何構建的。 這裡我們將談一些架構細節，並在以後逐步的公佈一些代碼。 第一篇文章，就將展示出全部的圖片。 好吧，實話告訴你，我們就只有這麼一張：

我在之前的報告中提到過每層都是一個成本投資。 事實上，最初我們沒有「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應用將得到新的提升。

有以上是所有服務層的介紹，更多細節將在續篇中得以報告。 （編譯/仲浩 王旭東/審校 原文來自collectedit ）

(責任編輯：蒙遺善)