現有應用程序的適配器模式

Question

我有一個寫得很久的應用程序。部分應用程序從DB獲取字符串（這是一個日期）並將其顯示在屏幕上。

由於DATE轉換爲字符串並存儲在數據庫中。顯示它時，字符串（DATE）從數據庫中恢復並顯示在Winform上。

現在，我們有一個要求，我們需要支持法國客戶和法國後續的DMDMMYYYY格式。我想在數據庫層和UI層之間使用adpater模式。根據區域設置轉換DATE格式的適配器。

1. 我的問題是，在這個senario中，我必須創建此適配器的一個對象。因爲我正在開課修改。不違反開放原則。

2. 是使用適配器模式的正確方法。當客戶端應用程序正在使用時（在這種情況下，人們在過去5年中使用它）可以使用適配器模式嗎？

3. 或其他任何方式來改變功能，以支持客戶的要求。

謝謝 戒

Answer 1

這是您的域邏輯從表現邏輯和持久性分開一個很好的做法。

而你在說的DB layer和UI layer之間的適配器似乎是domain model。

Answer 2

適配器模式用於將現有接口轉換爲客戶端需要/期望的接口。但它聽起來像你需要的是重新格式化的日期 - 它仍然是一個字符串。這聽起來不像適配器本身的工作。

使用適配器模式，理論上你不應該打開你現有的類。適配器包裝待修改的類並公開新的接口。我想象的是，適配器類將不得不通過所有未改變的公共事物，因爲客戶理想地只與適配器「對話」，而不是原始類。

的一般解

的總體思路是重新格式化該日期之前，爲了UI控制被設置爲值。我希望你的UI控件類有事件發生在事件發生之前。

是您在C＃中的應用程序嗎？它使用.NET綁定類嗎？

.NET Binding類有2個非常非常方便的事件：Parse和Format。他們在生活中的目的是讓你改變格式，值，類型，不管是什麼值來回走動。 您不應該修改任何現有的接口或現有的方法代碼。您添加事件處理程序來重新格式化日期字符串。如果你有一個很好的理由來打開你的類進行修改，然後OK

開/閉原則不是絕對的
。但是要記住開啓/關閉的一些隱含目標：

• 不要改變現有的接口（S）
• 不要改變現有的行爲。我們正在添加新的東西，我們不希望意外更改現有的東西。
• 修改代碼比編寫新代碼更容易出錯。

開/關是不是一個藉口：

• 不重構壞代碼來實現一個健全的修復
• 做了困境決定開放的緣故/關閉