2016 年 5 月

第 31 卷,第 5 期

本文章是由機器翻譯。

技術最前線 - 建置歷程 CRUD

Dino Esposito | 5 月 2016

Dino Esposito1970 年代以來就關聯式資料庫已經存在和幾個層代的開發人員開始和結束而不需要學習,或只是稍微考慮另一種資料儲存體的事業。最近,大型的社交網路提供關聯式資料庫無法處理所有的商務案例的強式辨識項。您的方式 (真正) 大量無結構描述資料時,關聯式資料庫有時可能會是一個瓶頸,而不是管道。

您可以想像可能需要立即計算上對某篇文章中全方位關聯式資料庫,使用一些十億名記錄總註解朋友喜歡什麼嗎? 更何況,固定的結構描述限制某篇文章的定義是最少具挑戰性。只有幾個商務存活,在某個時間點的社交網路演進,並將其儲存體焦點移動至混合的關聯式與非關聯式資料存放區,因此正式開啟多語言資料的商務。

基本學到的社交網路的軟體架構是您的資料有時候一般儲存體、 business-wise,理想的方法。而不是只儲存了任何資料,最好儲存事件發生特定事件的相關資料的相關詳細資料。

本文中,我會先找出事件來源的商務基礎 — 使用做為主要資料來源的應用程式記錄事件,然後再討論如何重新整理現有的建立、 讀取、 更新、 刪除 (CRUD) 技術,根據事件。若要清除從一開始,問題在於不您是否需要事件來源。問題在於當您需要與您撰寫的方式。

向動態資料模型

使用多語言資料現在是熱門話題 ︰ 無結構化資料的 NoSQL 資料存放區、 喜好設定及記錄的索引鍵-值字典結構化資料的關聯式資料庫圖表的關聯性和相互關聯的資料庫。介紹不同的儲存體模型執行並行所朝的方向沒錯,但我看來更類似於來組成實數及基礎疾病治療明顯徵兆有效尋求解決。

關聯式模型欠一組平衡的優點,它會提供讀取和寫入資料至其十年來長時間效率。關聯式模型很簡單查詢和更新,即使它會顯示在某些極端 (超短) 的情況下的限制。整體效能 comprehensibly 一些數百萬筆記錄與一些數百個資料行的資料表上會降低。此外,資料的結構描述固定的資料庫結構的知識,才能建立臨機操作和快速的查詢。換句話說,在您撰寫程式碼在今日的世界裡,完整的模型,像大注入了嶄新的關聯式模型,是先最後會限制您表達的龐大條件約束和更新版本中,您的程式設計功能。在結束時,模型是只是一種模型,是沒有什麼您觀察直接在真實世界中。在真實世界中,您不會看到任何模型。相反地,您可以使用模型封裝某些熟知且可重複的行為。最後,在真實世界中,您觀察事件,但要受條件約束 (關聯式) 模型中儲存事件的相關資訊。當這證明難做到時,查看剛發行一些結構描述和編製索引的條件約束的替代儲存體模型。

以事件為基礎的儲存體模型

數十年,很有幫助且功能強大儲存只是實體的目前狀態。當您儲存指定的狀態時,您會覆寫現有的狀態,因此會遺失任何先前的資訊。這種行為並不值得鼓勵,或本身怪。多年來,它已經證實為有效的方法,並獲得廣泛接受。只有商務網域和客戶可以真的說是否可以接受遺失任何過去的狀態。事實說多年,對於大多數企業是可接受。這種趨勢正在改變越來越多的商務應用程式需要追蹤的商務實體的完整記錄。什麼多年來呼叫 CRUD — 一般的建立、 讀取、 更新、 刪除作業 — 和之上純現在在什麼可以以一般方式稱為歷史 CRUD 發展關聯式資料表模型化。歷程記錄的 CRUD 是只要 CRUD 程式碼基底實作會追蹤整個變更清單的管理。

真實世界是完整的特定業務 (LoB) 系統以某種方式追蹤事件,因為它們發生在網域中。應用程式的這種類別存在數十年 — 甚至 COBOL 或 Visual Basic 6 中撰寫一些。當然,比方說,會計應用程式會追蹤可能會發生的所有變更發票例如日期或地址,發出通知單和類似的變更。在某些企業案例中,追蹤事件已要求的功能自早期的軟體,通常落在更廣泛的概括性的稽核功能。

因此,稽核商務事件不是在軟體中的新概念。數十年,開發團隊解決相同的問題,重新設計並重新已知的技術可能可找到的最佳方式。現在,舊的稽核商務事件的最好跳下更吸引人的事件來源名稱。

撰寫程式碼將商務事件

讓我們假設您有一個可讓使用者在活頁簿的共用的資源,像是在概念上簡單的應用程式輸入會議室。當使用者檢閱指定登記的狀態時,她可能有不只是預約的目前狀態,但更新整個清單建立之後。[圖 1 描繪可能時間軸型的 UI 的檢視。

時間軸型預約的整個歷程記錄檢視
[圖 1] 時間軸型檢視預約的整個歷程記錄

就設計方式預約資料模型的行為模式為歷史的 CRUD 而不是單純的狀態為基礎 CRUD? 多個資料行加入資料表定義仍嫌不足。CRUD 和歷程記錄的 CRUD 之間的主要差異是實體的在第二個案例中您想要儲存多個相同,它是實體的在指定的時間進行瀏覽每個商務事件每一個複本。[圖 2 顯示可能的新結構預約資料表的關聯式資料庫。

可能的關聯式資料模型的歷程記錄的 CRUD 應用程式
[圖 2 歷史 CRUD 應用程式的關聯式資料模型

資料表屬 [圖 2 具有預期的一組完整呈現的商務實體,再加上幾個其他的狀態的資料行。起碼您想要有主索引鍵資料行來唯一識別資料表中的資料列。接下來,您會想要有時間戳記資料行,指出資料庫作業的時間,或是對商務意義的任何時間戳記。更一般情況下,資料行的用途是做一個安全的日期,以實體狀態產生關聯。最後,您會想要有一個描述所記錄之事件的資料行。

它仍然是關聯式資料表,並且仍然管理的預約清單應用程式的需要。已新增任何新技術,但資料表在制式化的概念上 [圖 2 是從傳統 CRUD 一大進展。將記錄加入至新的資料表很簡單。您剛剛填寫的記錄,並將它們附加,因為您會收到通知,發生了什麼事情必須關閉追蹤系統中。太多的 CRUD; 在 C但是其他作業呢?

更新與刪除在歷程記錄的 CRUD

一旦已插入歷程記錄,以事件為基礎的資料表開啟傳統的關聯式資料表,角色及相關的更新和刪除大幅的變更。首先,更新會消失。邏輯狀態之實體的任何更新,現在都實作為新附加追蹤記錄的新狀態。

刪除作業會需要技巧的點,如何撰寫其程式碼的最後一個字位於該網域的商務邏輯。在理想的事件基礎世界,有任何刪除。資料只加總,因此刪除則是只是加入新的事件,以通知您,此實體以邏輯方式已不存在。不過,實際移除資料表的資料法律不禁止,且仍有可能發生。請注意,雖然,事件架構案例中,要移除的實體不由單一資料錄,但是包含一組的記錄,如下所示 [圖 2。如果您決定要刪除實體,則您必須先移除所有事件 (和記錄),相關的。

讀取之實體的狀態

您可以記錄在您的應用程式的商務事件的最大好處是,不會錯過任何項目。可能在任何指定時間追蹤系統的狀態、 找出造成指定的狀態和復原的動作順序,總計或部分,這些事件。這奠自我提出的商業智慧和假設狀況商務分析。若要更精確,將不會自動取得即將現成的應用程式,這些功能,但您已經有您要開發此類擴充現有的應用程式上的任何資料。

最困難的歷程記錄的 CRUD 部分讀取的資料。您現在追蹤關閉所有相關的商務事件在範例預約系統中,但是沒有地方,您可以輕鬆地取得常設預約的完整清單。沒有快速簡單的方法可以知道,說有下週多少預約。這是投影適用於什麼情況。[圖 3 摘要說明從一般的 CRUD 發展歷史的 CRUD 至系統的整體架構。

歷程記錄的 CRUD 系統的架構
[圖 3 的歷史 CRUD 系統架構

以事件為基礎的系統是無可避免地專實作命令和查詢堆疊之間有明確的分隔。從展示層中,使用者就會觸發的工作,就會繼續進行應用程式和網域層級包含所有商務邏輯元件的方式。命令會為目前的系統,也就是說,必須有以邏輯方式認可的狀態會改變的商務工作的觸發程序會修改現有的狀態。中所述,以事件為基礎的系統 — 即使系統是單純、 簡單的 CRUD 系統 — 改變狀態表示新增記錄,指出使用者建立或更新特定的預約。中的區塊 [圖 3 標示為 「 事件儲存機制 」 代表的程式碼的任何一層負責保存事件。具體技術,根據事件存放庫區塊可以是 Entity Framework 為基礎的儲存機制類別,以及文件資料庫 (Azure DocumentDB、 RavenDB 或 MongoDB) 的包裝函式。甚至更有趣的是,它可以使用例如 EventStore 或 NEventStore 事件存放區 API 的包裝函式類別。

事件為基礎的架構,在收到要求時優良計算指定之實體的狀態。此程序的事件重新執行名稱之下,並且包含查詢指定的實體與相關的所有事件,並將它們全部套用至新實體類別的新執行個體。在迴圈結束時,因為它具有瀏覽所有記錄的事件的新執行個體的狀態,是最新的實體執行個體。

更一般情況下,處理的事件記錄檔建立的資料投射並擷取超出資料量較低層級的動態資料模型。這是什麼指中讀取模型 [圖 3。在相同的事件記錄檔中,您可以建立提供各種不同的前端的所有資料模型。若要使用 SQL 比喻,建置記錄的事件資料的投影是建置出關聯式資料表的檢視相同。

重新執行事件,以判斷實體的查詢用途的目前狀態通常是可行的選項,但是會變得越來越不有效的事件數目,或要求的頻率會隨著時間。您不想要逐步執行一些幾千個記錄每次只以找出目前的銀行帳戶餘額。同樣地,您不打算逐步數百個事件,以提供一份清單,暫止的預約。若要解決這些問題,讀取的模型通常會以程式設計方式保持與記錄的事件資料表的同步處理的傳統關聯式資料表的形式。

總結

大部分的應用程式可以仍然大致分類為 CRUD 應用程式。相同的方式 Facebook 可以呈現以某種方式為 CRUD 比平均也許有點大。說真的,對大多數使用者最後一個已知的良好狀態仍不夠,但此檢視是不夠的客戶數目成長。接下來可能會是您最佳的客戶。這篇文章被皮毛剛才的歷程記錄的 CRUD。下個月,我將提供具體的範例。下次見!


Dino Esposito是每個 「 Microsoft.NET: 架構的企業應用程式 」 (Microsoft Press,2014年) 和 [使用 ASP.NET 最新 Web 應用程式] (Microsoft Press,2016年)。.NET 和 Android 平台在 JetBrains,並在世界各地的產業活動的技術推廣人員 Esposito 分享軟體的願景 software2cents.wordpress.com 和 Twitter: @despos

感謝以下的微軟技術專家對本文的審閱: 喬恩 · Arne Saeteras