[Windows Azure] Windows Azure 對 MSDN 訂閱戶服務的改變

如果有訂閱 MSDN (或是你是微軟 MVP 又有訂閱 MSDN Utlimate Subscription) 而且又有在使用 Windows Azure Member Offer for MSDN Subscription 的人請注意,微軟將在 2013/8/1 起變更 MSDN 訂閱戶的權益,將原本固定額度資源的方式改變為以配發免費額度的方式,亦即原本是以資源與使用額度 (Resource-based) 的優惠限制,改為給予抵用金 (Credit-based) 的方式,這樣的作法對微軟來說可以更有效的控制與分配資源,但對我們這些已經在 Windows Azure 平台上做實驗以及使用資源的人來說就未必是件好消息了。

...繼續閱讀 »

[.NET][LINQ] Any() vs. Count() 何時可用? 何時不可用?

LINQ 語法中有兩個很令人玩味的方法,一個是 Any(),另一個則是 Count(),Any() 的功能是判斷集合中是否有物件,Count() 則是用來計算集合中的物件數量,功能其實很像,以一般的使用習慣來說,我們多半會使用 Count() 來判斷集合中是否有物件,而且在大多數的情況下是沒問題的。

...繼續閱讀 »

[Windows Azure] 將 Table 的 Entity 結構由 ITableEntity 中解放吧

Windows Azure Platform 的 Table Storage 是一個結構化的資料儲存地,一般來說 (連我的書也是這麼寫),在使用 Table 之前,我們需要對 Table 中的資料列做型別宣告,也就是要建立一個 Table Entity 的類別,然後用 DataServiceContext.AddObject() (Storage Client 1.0) 或是 TableOperation.Insert (Storage Client 2.0) 來存取它,但這對於很多 NoSQL 的應用很難適應,因為 NoSQL 是 Free-Schema,但 Table 的 Entity 限制反而形成了 Schema,對 NoSQL 應用有相當的副作用...

...繼續閱讀 »

[Data Access] ORM 原理 (11): 效能議題

這絕對是 ORM 的使用者,開發人員與 DBAs 共同想要問的議題,到底我使用了 ORM 和使用傳統的 ADO.NET 下 SQL 指令的方式會差多少? 這個問題不但會發生在 Entity Framework 上,也會發生在 NHibernate 等 ORM Framework 內,連同我自己在這個系列文中開發的 ORM 機制也會受到影響...

...繼續閱讀 »

[Data Access] ORM 原理 (10) : 全程式碼對映–當 ORM 遇到 Lambda 與 Fluent Interface

ORM 原理前面8集中己經講述了基本的ORM核心內的運作方式,大多數的ORM其實都是這麼做,當然還會做一些更進一步的最佳化工作,例如產生SQL的方式等。不過既然都是寫程式的,當然會希望這些對應欄位的設定工作可以完全的程式化 (Coded Map),而不用再假手那麼多的設定檔。

...繼續閱讀 »

[Windows Azure] 使用 Windows Azure Access Control Service 2.0 開發 ASP.NET MVC 單一簽入應用程式

單一簽入 (Single Sign On) 一直是驗證存取權機制的最終境界,整合單一簽入的技術在市場上早已炒到不能再炒了,而且也有相當多的單一簽入解決方案,其中包含 OAuth 1.0/2.0,Open ID,Active Directory,LDAP 等等協定和服務,而在社群網路流行後,幾個重要的大型帳戶儲存庫像 Facebook, Google, Yahoo, Twitter, Plurk, Linked In 等廠商也相繼的開發了認證的 API 群,以支援來自不同設備或用戶端的驗證需求,而在台灣最新的個人資料保護法正式施行前,外部的單一簽入已經成為應用程式認證機制的首選,尤其是小型網站或新進市場的應用程式,透過大廠來處理驗證,使用者不但不用記太多的帳戶密碼,也容易吸引使用者登錄資料...

...繼續閱讀 »

[Windows Azure] Spring Release 新功能五部曲:全新的快取模式

Session State 和雲端應用程式狀態管理一向是設計 Cloud 應用程式的重要考量因素之一,因為雲端應用是分散在不同的虛擬機器內執行的,VM 間可應用的大概只有像資料庫或 storage 這種集中式資料來源,而且雲端應用的儲存也都是分散式的,若是有一個地方能快取這些資訊,那麼就能降低分散環境的 I/O 負擔,應用程式的回應速度也會比較快,所以才會有 Windows Azure Caching Services (原稱 AppFabric Caching Services) 的出現,只是有個問題,就是它有點貴:128MB 的快取要 $45 美元月費,而中大型應用程式的快取通常需求又很高,同時 Caching Services 也是分散式的環境,所以還是有 I/O 的問題。

...繼續閱讀 »

[Windows Azure] Spring Release 外傳:品牌名稱的改變

Spring Release 除了看得到的改變外,有一項隨處可見但沒有被大書特書的改變,大概就是整個產品線的重新命名吧,一開始的時候整個 Windows Azure Platform 是以三個產品線為主-Windows Azure, SQL Azure 與 AppFabric 三個品牌,經過兩年的推廣,很多人都不知道這三個品牌是系出同門,也就是都是 Windows Azure Platform 的一部份,而且 Windows Azure AppFabric 和 Windows Server AppFabric 是不同的技術 (雖然都有 AppFabric 這個字),相信連微軟自己都很頭痛,所以這次的 Spring Release 中,微軟對整個 Windows Azure 做了產品線的檢視,並將必要的產品線名稱重新拉回到 Windows Azure 之內,不但可以讓業務在解釋產品時能更聚焦,也能讓看到這個品牌的人明確知道這就是 Windows Azure 下的產品,而不是一個獨立產品。

...繼續閱讀 »

[Windows Azure] Spring Release 新功能四部曲:虛擬網路服務 (Virtual Network Services)

這篇基本上是寫給 IT PRO 看的,身為開發人員看不懂沒關係,因為網路設定這部份通常不會是由開發人員來做的,尤其是複雜的 Gateway, DNS, DHCP 以及主機設定,包括以前在學校或電腦補習班學的子網路 (subnet) 知識,以及路由表設定的知識等等。之所以要使用虛擬網路服務,是為了配合之前所報導的 Virtual Machine 服務,主攻企業混合雲 (Hybrid Cloud) 基礎建設,也就是在雲上的基礎建設服務 (Infrastructure Services),MIS 人員能直接在 Windows Azure 資料中心內建置自己的虛擬機以及網路環境,再透過 VPN 連接本地端的網路,形成混合雲的完整基礎建設。

...繼續閱讀 »

[Windows Azure] Spring Release 新功能三部曲:Windows Azure Website 角色

以往 Windows Azure 上可執行應用程式的角色,只有 Web Role 和 Worker Role,這兩個角色都要由開發人員上傳應用程式套件到雲上,而且還要自行設定許多的組態 (ex: Database) 才能啟用,就算使用者只想要用簡單的方式來建置自己的網站,也還是要先學習 Visual Studio 和 Windows Azure 開發才行,似乎對一些只有簡單需求的使用者來說門檻有點過高了,而且微軟自己已經有了一個 Web Platform Installer,裡面有豐富的 Web Application Gallery,許多開放原始碼的現成套件都在裡面,使用者也許只需要用這樣的套件,而不是一定要自己親手開發。

...繼續閱讀 »

[Windows Azure] Spring Release 新功能首部曲-全新的 Management Portal 入口網站

Windows Azure 這次的 Spring Release 大改版,最令人期待的亮點,就是整個管理入口網站正式改版,這個全新的入口網站使用了 HTML5 技術,並配合 AJAX, OData Services 等技術開發而成,依筆者個人實測速度,比前版快至少一倍以上,而且重新整理的時間也縮短了。

...繼續閱讀 »

[Windows Azure] Spring Release 快速預覽

對於 Windows Azure 來說,明天 (美國時間 6/7) 是很大的日子,最新的 Windows Azure Platform Spring Release 在明天就要正式開放,除了台灣正式納入 Windows Azure Platform 的服務範圍外,整個平台有較大幅度的服務與功能新增,其中有數項功能是針對企業用戶的私有雲 (Private Cloud) 而來,微軟希望在新的 Windows Azure 平台上能和企業的私有雲整合,將混合雲 (Hybrid Cloud) 的概念更完整的實現。

...繼續閱讀 »

[Data Access] ORM 原理 (9) : 資料的新增,修改與刪除

到原理 (8) 為止,我們已經完成了資料的查詢工作,但資料庫應用程式不是只有查資料而已,對資料的新增,修改和刪除 (C/R/U/D) 也要實作,才算是具有完整的資料存取能力,所以我們也必須要做到 C/U/D 才行,對程式來說,C/U/D 比 R 要簡單,但還是會有一些需要考量的地方,首先,在一堆資料的集合物件中,大部份的情況下不是每一筆都需要做 C/U/D,怎麼判斷每一個物件的狀態,以及在處理物件時何時更改狀態,就是一個重要的課題了,再者,如何產生資料庫需要的 INSERT/UPDATE 和 DELETE 指令,也是我們需要關心的。

...繼續閱讀 »

[Data Access] ORM 原理 (8) : 集合處理與 Lazy Loading

在原理 (7) 中,我們完成了關聯的基本處理,只是我們做到的是一對一的關聯,如果今天要的是一對多的關聯時,我們就需要處理到集合物件,集合物件不像單一物件那麼簡單,尤其是集合物件的元素又和其他物件有關聯時,載入的方式就會決定程式的速度,以我們到目前為止的例子,Customers, Orders 和 Employees 三個表格,Customers 會和 Orders 有一對多的關係,而 Orders 和 Customers 與 Employees 有一對一的關係,我們在原理 (7) 中實作的是 Order 類別,所以是一對一,但如果我們要實作 Customers 和 Orders 之間的關係,會變成一對多,也就是我們要處理 Customer 類別內的 OrderCollection 集合物件...

...繼續閱讀 »

[Data Access] ORM 原理 (7) 物件關聯性

資料關聯 (data relation) 是 DBMS 的特色之一,它通常也是和物件難以整合的重要因素,因為物件的關聯和資料的關聯是不同的,物件的關聯是在物件內以屬性的方式連接另一個物件,但資料的關聯是在兩個表格之間以鍵值資料 (key) 串接,且 SQL 指令會透過 JOIN 指令 (不論是 INNER, OUTER 或 FULL) 來撈取關聯的資料,只是如果要在 ORM 內實作這樣的機制,勢必會有不小的難度,因為 JOIN 指令要由 ORM Framework 來產生,而且在取得關聯資料時,ORM Framework 未必會直接撈取關聯資料,而是在存取行為發生時才會實際填入資料 (又稱為延遲載入),後者要判斷的事就更多了。

...繼續閱讀 »

[Data Access] ORM 原理 (6) : 單純化資料存取程式

ORM 原理走到第六步,核心只會愈來愈複雜,但用戶端相對會變得簡單,會寫這一系列文的用意,是告訴大家 ORM 的核心大概的作法,像 NHibernate 或 Entity Framework,核心做法其實差不多,當然這些著名的 ORM Framework 一定沒那麼簡單,還有很多的配套功能要做,只是我想告訴大家的是,ORM 本身不會因為它看起來像物件就可當沒有 SQL 這回事,當物件存取和關聯愈來愈複雜的時候,Object 和 SQL 之間的互動複雜度就會成等比級數一樣。

...繼續閱讀 »

[Data Access] ORM 原理 (5) : 欄位對應的進階考量

在原理 (4) 中,我們使用了特徵項 (attribute) 來處理欄位對應的問題,只是這個方法對於可能時常異動欄位名稱,或是想要利用 copy/paste 以及擴大使用範圍的需求來說,可能就沒那麼恰當,因為使用特徵項最大的缺點就是:它是寫死 (hard-code) 的,若是想要修改欄位名稱的話,勢必又要重新 compile...

...繼續閱讀 »

[Data Access] ORM 原理 (3) : 處理列舉型別 (Enumeration Type)

我們在原理 (2) 中處理了許多內建的型別,不過還有幾種比較棘手的型別,其中一個就是列舉 (enumeration),列舉也是一種實值型別,只是它大多用來作為限制常數的用途 (使用有意義的指令取代數字),而且它不能用在泛型,所以 where 等於是不能用 (雖然有替代方案)。

...繼續閱讀 »