2009-05-28 19 views
1

我會盡量保持這個例子儘可能簡單。 我試圖在舊的VB6應用程序中實現一個域驅動的設計(一個業務對象來表示每個表),它不遵循OOP模式。現有代碼的編寫方式與您從10年前的VB應用程序中所預期的相同(即使用ADODB.Recordset不帶字段的智能感知)。現有的代碼是非OOP的,並且我不敢遵循現有的模式。 這裏面臨的一個挑戰是如何在新需求出現時處理數據庫更改,而不會對任何可能稍後查看DB設計的開發人員造成太多混淆。從未標準化的寬表中清理出來

假設在此應用程序,我們有一個假設的「客戶」表,這顯然是不堪重負的這樣: 的clientId CLIENTNAME聯繫人姓名地址城市州郵編電話CREDITLIMIT CurBalance(和和和...)

的InterestRate條款

難道是可以接受的,打破的InterestRate和條款到一個單獨的「Fiancials」表,這可能會出現,因爲現有的2個金融領域一個奇怪的分裂將存在:新的金融領域

新的要求需要原來的桌子?

理想情況下,舊金融字段(CreditLimit,CurBalance)將被重新定位到這張新表格,但面臨破壞應用程序多個部分的風險,移動字段並不可取。我只想停止目前製作更寬更寬的桌子的做法。

基本上,我想我想單獨留下舊的代碼/表格設計,使用新字段進行乾淨的休息,並創建域對象來處理任何現有的和新的表格,即客戶端對象可能會暴露表示新的財務屬性財務表。

嘗試做一個乾淨的休息或只是添加新的領域到現有的糞便是一個好主意? 是否有一個巧妙的命名方案來表示新表與舊錶? DBA如何在不破壞現有設計的情況下進行乾淨的休息?

感謝您的任何想法

回答

1

您可以使用視圖。您可以這樣做,以便客戶端視圖不再公開財務信息,並創建財務視圖以公開信息。他們共享相同的基表並不關心最終用戶,因爲...

然後您拒絕對錶的所有訪問,並且只能通過存儲的特效和視圖進行訪問,然後您可以隨時重構您的表。

或者,您可以重命名錶並拆分它並在舊錶名下創建一個視圖。

重要的是要記住的是,業務對象不映射1-1到表。會有關係鏈接表(例如client_account鏈接客戶端到賬戶,比如說),但是關係沒有業務對象,取而代之的是客戶端對象通常會有一個賬戶集合和/或反之亦然,這取決於設計約束。

0

根據您正在訪問的數據庫,另一個涉及視圖的選項是使用正確的規範化設置替換現有數據模型,然後使用舊錶的名稱創建視圖。因此,如果你今天有一個CLIENT表,你可以將它分成任何一組適合的表,並創建一個複製現有表結構的CLIENT視圖。假設視圖是可更新的(這可能需要類似Oracle的INSTEAD OF觸發器),現有代碼只會訪問視圖並且不需要更改。新代碼可以訪問正確的數據模型(直接或通過另一組視圖,這些視圖可讓您自由地在將來演變數據模型而不影響應用程序代碼)。由於您有時間重構現有代碼,因此您可以將其指向新的數據模型。