我們在原理 (1) 時,看到了看似很完美的屬性與欄位對應,因為屬性和欄位名稱一致,在處理起來算是很容易,但現實的情況是,屬性名稱未必會和欄位名稱一樣,這時我們就需要一套方法來處理欄位與屬性的對應。
[Data Access] ORM 原理 (4) : 處理自訂屬性與欄位對應
- 9594
- 0
- .NET Framework
- 2022-05-10
我們在原理 (1) 時,看到了看似很完美的屬性與欄位對應,因為屬性和欄位名稱一致,在處理起來算是很容易,但現實的情況是,屬性名稱未必會和欄位名稱一樣,這時我們就需要一套方法來處理欄位與屬性的對應。
我們在原理 (2) 中處理了許多內建的型別,不過還有幾種比較棘手的型別,其中一個就是列舉 (enumeration),列舉也是一種實值型別,只是它大多用來作為限制常數的用途 (使用有意義的指令取代數字),而且它不能用在泛型,所以 where 等於是不能用 (雖然有替代方案)。
我想大家或多或少都聽過 Entity Framework 或是 NHibernate Framework 這種大型應用程式開發的 Framework 吧,它們都是做 ORM (Object Relational Mapping) 技術的資料存取函式庫,只是很多人都只看它有什麼功能,卻沒有多少人對它內部感興趣-為什麼它們可以精確的對應 SQL 的欄位和物件屬性呢?我試著以一系列的文章來介紹 ORM 到底做了什麼事。
我們首先了解了 ORM 的繫結物件屬性與欄位時使用的方式,只是還有個問題,就是我們原先用的屬性型別都是 string,很好處理沒錯,但大多數的資料結構沒這麼簡單,一定不會只有 string 型別,像 int, double, long, char, boolean 這些型別也時常出現,那麼要怎麼處理這些型別間的轉換?
早期企業在打造應用程式時,除了少數較宏觀的主導者以外,多數都是按照當下的需求以及業務條件來發展的,很少會有考量到軟體特性(例如Scalability、Extensibility、Maintainability等)的規劃。隨著時代的進步,物件導向程式設計與系統分析的發展,讓資訊產業開始重視軟體元件(Software Component)的概念,軟體元件的可重覆使用性愈高,則軟體元件的效益就會愈高,同時也代表該軟體的價值也愈高。但只要是在資訊產業涉足一段時間的人,通常都會知道資訊產業的主流總是掌握在幾個大廠商或是領導社群中,企業需要在不同的廠商標準間將內部所有的系統整併以維持或強化企業的資訊體質...
繼前一天的VM Role作業,我們已經成功的上傳了自訂的 VM Role 基礎作業系統影像 (base operating system image),接下來就是在 Visual Studio 中使用這個VM Role。VM Role 和 Web Role/Worker Role 不同,它擁有自己的組態環境,不像 Web Role/Worker Role 是可以在上面建置專案,也就是說,企業的應用程式必須要在 VM Role 中都設定好以後,再將 VHD 上傳到 Windows Azure 資料中心。當然,你也可以使用 Remote Desktop Connection 的檔案上傳來傳送檔案,但是速度不會比直接在 VHD 組態好後再上傳來的快。
在今年九月的時候,收到來自於國外一間出版公司 Packt Publishing 的電子郵件,邀請我為他們的書 Microsoft Windows Azure Development Cookbook 寫篇書評,當時我原本是因為語言的關係回絕,但他們回覆說允許我使用繁體中文來撰寫,所以我就答應了,但因為很來事情實在太多,應接不暇,所以才拖到現在寫,對他們是有些抱歉 ...
Windows Azure Platform一開始的設計大多是以開發人員為中心,因為它是一個Cloud Platform,要先吸引開發人員的目光,才會讓它的應用變得更廣泛,但是雲端運算不是只有開發人員的任務,在應用程式發行之後,維運則是MIS與企業內的IT人員的工作,所以在1.3版開始,微軟慢慢的加入了與MIS維運有關的功能,其中一項就是Remote Desktop Connection(遠端桌面連線)。
開發雲端應用程式的思維可不能像平常開發應用程式一樣,我們每天在開發應用程式時,都能運用除錯器來偵錯,或是調台近端的主機上傳測試用,或是公司自己有自動化測試的機制,然而當應用程式上了雲端環境後,這些習慣幾乎通通不能用了,原因很簡單,雲端應用程式執行的地方可能是離你幾千公里外的公有雲機房,我們不可能在機房內掛除錯器偵錯,就算要上傳也要幾經思量(要錢),但是我們又希望能夠記錄或測量應用程式的執行細節,這時我們能夠用的,就是Windows Azure Platform本身的診斷服務(Diagnostics Service)。
Drive Storage是Windows Azure SDK特別為.NET的開發人員所準備的一個儲存格式,它只存在於Windows Azure SDK的組件和API中,它並沒有對外的REST APIs,除了使用Windows Azure SDK外,沒有別的方法可以使用,它本身是基於Page-BLOB為主的儲存服務,但將它模擬成一個獨立的磁碟機供應用程式使用...
學過資料結構的人一定都聽過Stack和Queue吧,Stack是後進先出(LIFO),而Queue則是先進先出(FIFO)的資料結構,商用系統的實務開發上,Queue的應用範圍比Stack要大的多了,因為在實務上會用到先進先出的案例太多了,舉凡線上訂位(購買)、抽號碼牌、選位等等商用的需求都會要求先進先出的條件,故Queue的應用範圍會比Stack大的多,微軟當然也很清楚這一點,所以在Storage中也實作了一個專門處理Queue的服務,即為Queue Storage。
Table Storage是一個模擬關聯式資料庫的結構化資料(structured data)存取服務,它就像是在雲端中的表格一樣,允許應用程式可以在Table儲存體中宣告並存取自己的資料結構。而在Table儲存體的內部,則是橫跨多個伺服器與磁碟儲存區的基礎架構,微軟的Windows Azure開發小組將核心內的所有作業都隱藏起來,只顯露出一個REST API供外部應用程式存取,而且都是透過相同的URL來呼叫,因此Table基本上並不是儲存在應用程式所在的VM,而是在Windows Azure Platform內部自動規範的儲存區域中。
BLOB Storage顧名思義,是專門用來儲存二進位檔案使用的儲存服務,基本上檔案的格式沒有任何的限制,只要是可以轉換成二進位資料(binary data)的檔案都可以儲存,也就是我們常說的非結構化(unstructured)資料,舉凡一般的文字檔案到大型的影音檔案都可以使用。
作為應用程式以及其他類型線上服務的核心平台,Windows Azure Platform除了針對雲端運算的基礎建設、營運與管理部份特別設計並支援外,它也必須要具有應用程式以它為基礎開發服務的相關支援,以一個作業系統來說,除了硬體與運算資源的分配與控管外,對軟體最直接最基本的支援,非儲存功能莫屬。如果沒有儲存功能的話,作業系統只能執行運算,而不能利用近端的媒體來儲存資訊,因此作業系統必須要有儲存的能力,才能夠達到開放給應用程式發展的最低限度服務。
在完成Cloud Application的開發也完成本地的測試後,我們就可以將應用程式發行到雲端環境了,當然,使用者必須要先申請到Windows Azure Platform的帳戶,然後登入到Windows Azure Management Portal建立新的主機服務(Hosted Service),才可以進行上傳的工作。
為了要讓開發人員無需為了測試簡單的功能就不斷的在雲端環境和本機間來回,所以特別準備了一個在本機上模擬雲端環境的工具,稱為Windows Azure Simulated Environment...
經由前幾天的知識補給後,我們來寫一支簡單的Cloud Application吧,當然第一次用要先向Windows Azure說聲Hello,所以第一支程式就以Hello Windows Azure來實作吧。
Cloud Platform要提供的是與雲端軟體有關的APIs以及開發介面,讓軟體可以和基礎建設連結,它還負責將基礎建設提供的資源進行抽象化,雲端軟體的開發人員只要透過由Platform抽象化後的APIs即可使用基礎建設內的各式資源,無須了解基礎建設的實作細節。
Windows Azure Platform是微軟的雲端運算藍圖中,公有雲(Public Cloud)端的解決方案,就如同在桌面與伺服器上的Windows作業系統一樣,它擁有自己的作業環境、資源配置以及資訊交換與控制等等的核心架構,提供儲如運算服務(Compute Services)、儲存服務(Storage Services)、網路服務以及核心端的監管與安全服務等等,可將它視為是一個公有雲上的Windows作業環境...
繼前一篇 Windows Azure SDK v1.5 announced 文章,我們再介紹幾項 SDK v1.5 以及其他相關服務的新功能吧。
這次 9/13-15 在老地方 (TICC) 舉辦的 Microsoft Tech.days 2011 Taiwan,筆者受邀當 COS 課程的講師,這次所主講的是 SQL Azure Overview 以及程式開發人員比較感興趣的 Windows Azure Service Management APIs 的開發。
在 9/13-16 舉行的 BUILD WINDOWS (其實就是以前的 PDC 啦) 研討會中,除了眾所矚目的 Windows 8 和 Visual Studio "11" 以外,雲端當然也不會缺席,微軟在 9/14 的 Keynote 2 中發表了 Windows Azure SDK v1.5,並隨著新的 Visual Studio Tools for Windows Azure v1.5 一起發表,這次的 Windows Azure SDK v1.5 中,除了以往功能的小部份增強外,還多了幾個有意思的功能。
Membership, Role 以及 Session State 這三樣是 ASP.NET 2.0 以後其後版本中的重要角色,ASP.NET 內建了數個 APIs 以及預設的 Providers,並透過 aspnet_regsql.exe 在 SQL Server 中可以建立必要的資料庫與表格,供 ASP.NET 應用程式使用。但是,在 SQL Azure 中,這個功能突然不能用了...
最近做了幾個在 Windows Azure 上架設服務的案子,都有涉及到使用 Windows Azure Platform 的費率的計算 (要報價用),所以在費率的評估上略有心得,特別整理一下給未來想要使用 Windows Azure Platform 的參考。
本區為 Windows Azure 教戰手札書籍的技術支援區,以及書籍的勘誤等讀者服務區,不定時更新。
這個功能是在設計 Facebook Graph API Client Library 時碰到的問題,在 Graph API 中的 Publish_Stream 中有一項上傳相片的功能,這個功能內有一個 message 和 access_token 參數,而原本我們學習的 HTTP 技術本身大多都是沒有混合二進位和字串值的參數,所以當時碰到這個問題時,一時想不到什麼解決方法,後來搜尋到 RFC 2188: Returning Values from Forms: multipart/form-data,這份文件說明了在 HTTP POST 訊息中使用多種格式訊息的作法,它可以用在許多 REST-based API 的系統,它可以混合多種資料格式並一次傳送,當然非文字的資料必須要編碼為二進位字串。
筆者所講授的研討會或教育訓練課程 (可公開的) 的簡報彙總庫,可取用,但請註明來源,且此處資訊將不定期更新。
這是筆者的第二本著作,專為初入門的 Windows Azure Platform Developer 所寫,由雲端運算,Windows Azure 的系統架構,開發方法,儲存服務,到 SQL Azure 資料庫與 Windows Azure Platform AppFabric 等都有涵蓋,開發工具以 Visual Studio 2010 為主,程式語言為 C# (對使用 VB 的朋友只能說聲抱歉,但網路上已經很多語言互轉的工具可用了),若您是雲端開發的入門者,那一定不要錯過本書。本書簡體版已於大陸上市,書名為 "走进云计算:Windows Azure实战手记"。
本考試測驗考生對使用 .NET Framework 3.5 設計與發展 Windows Application 的專業能力,在 .NET Framework 3.5 中,Windows Application 包含了 Windows Forms 和 Windows Presentation Foundation,不過本考試專注的地方還是在 Windows Forms 應用程式部份,並且著重於設計應用程式時的技術評估與決策,在不同的環境以及軟硬體的限制下,要如何取用適當的應用程式元件來發展所需要的解決方案。
本考試測驗考生對於 Windows Forms 應用程式的開發熟悉度,雖然它是在 .NET Framework 3.5 中,但是它卻沒有太大變化,主因是 Windows Forms 本身並沒有太大的變化,但因為它週邊有些許變化(例如在 Windows Vista 中部署,WCF Service 以及 Client Profile Service 等等),而且微軟認為短期內 WPF (Windows Presentation Foundation) 要取代 Windows Forms 是不太可能的,這點在微軟沒有把 Exam 70-502: TS: Microsoft .NET Framework 3.5, Windows Presentation Foundation 列入 MCPD: Enterprise Application Developer 3.5 的要求可看出端倪。