規範化表併發檢查（ACID）

Question

問題的兩個部分：

1號：什麼是創建引用其他對象的對象模型，最好的辦法時，一些屬性/屬性引用的對象並不總是必要的？

試想一下，如果你有兩個對象：PERSON和BUSINESS

Person 
+ PersonID 
+ Name 
+ Age 
+ Sex 
+ Skill 
+ Business * 

Business 
+ BusinessID 
+ Name 
+ Address 
+ CorporateVision (this is large) 

在上面的例子：一個PERSON具有作爲其當前僱主的BUSINESS參考。

在數據庫中，我會爲每個對象有兩個表。在代碼中，使用MVC體系結構模式時，每個對象都有兩個類。該數據庫將具有BUSINESS之間的外鍵關係 - >PERSON，而在代碼PERSON對象將具有保持到BUSINESS對象的引用的成員變量。

現在讓我們說，我想枚舉的人士集合，並找出那些針對特定公司工作的總人數（基於BUSINESS。名稱）。

不使用MVC，我可以創建一個函數來查詢數據庫並獲得一個計數。簡單而有效。

在MVC中，我需要實例每PERSON對象，這反過來，實例化一個BUSINESS對象引用（如果不是已經做好了...... BusinessFactory將檢查集合第一）。此外，它必須拉業務。 CorporateVision從數據庫中爲每個對象。而且由於這些業務大部分都是媒體營銷公司，他們大部分的企業願景都是大文本塊。因此，當我們需要的只是業務名稱時，從數據庫中讀取CorporateVision是非常不必要的。

我可以有改變PERSON對象的代碼來解決這個問題：所以，現在當我創建我的PERSON對象

Person 
+ PersonID 
+ Name 
+ Age 
+ Sex 
+ Skill 
+ BusinessID 
+ BusinessName 

，我做BUSINESS一個JOIN和緩存名稱。現在，我可以快速有效地獲取BusinessName ...並且通過對ID進行查找，我仍然可以根據需要獲取完整的BUSINESS對象。但是我只是對模型進行了非規範化......而我剛剛介紹了一個新問題......並提出了一個新問題。

Number 2：MVC如何處理多用戶數據庫的併發性？

可以說，雖然我的客戶端應用程序正在枚舉（使用上面提到的查找所有人爲特定業務工作的枚舉），但另一個用戶合併了兩個BUSINESS對象。

現在我的內存中收集是錯誤的，因爲所有的BusinessName緩存都是陳舊的。如果我剛離開PERSON，情況也會如此。 業務作爲業務對象編號：業務對象將陳舊。

總結：我覺得使用MVC我失去了數據檢索效率以及我的應用程序的ACIDness的損失。或者我使用MVC錯了？

Answer 1

您似乎混合了UI和數據訪問，而您應該將其依賴關係最小化。 MVC實際上是一個非常廣泛的模式，它描述了應用程序如何與用戶進行交互。你的問題都與數據訪問有關。

1）MVC是你組織UI的方式。因此，模型是您想讓用戶與之互動的一條信息。請注意，這裏的業務對象並不重要。如果在使用時加載Person類以及來自Business的多個屬性，那麼可以這樣做：您的第二個人演繹是這種情況的完美模型。等等 - 每個用例需要不同的模型，您應該爲不同的場景創建不同的模型。

如果您認爲調用函數來計算數字會更容易 - 好的。請記住，您不受這裏的商業對象約束。

隨着越來越多的「面向object'的方法，我們通常有兩種方式解決這個問題的參考：

• 首先是延遲加載，用的是出的現成功能現代O /客戶經理。因此，您加載一個人，並在第一次調用Person.Business後，後者會自動加載。
• 其次是您創建了一種特殊類型的用戶界面，它知道您的數據訪問細節，並且只有您使用的字段，或者以異步方式從客戶端請求其他數據。

2）同樣，MVC不處理併發，它不應該處理它，甚至不應該打擾。這是數據訪問層的關注點。還有幾種方法來處理併發，其中主要是樂觀和悲觀的鎖定。 （第一種方法允許不同的用戶進行衝突的更改，並嘗試在發生衝突時解決衝突;第二種方法通過完全鎖定更新來防止衝突）。再次，O/RM通常處理它;或者你可以使用你自己的實現，但它應該仍然是數據訪問，而不是MVC部分。