2013-05-01 66 views
0

我很好奇什麼纔是在以下實現中使用的最佳設計模式:我創建了一個小型應用程序,用於從網站下載圖像並將其設置爲我的背景。如何從業務邏輯中分離遠程數據訪問(通過http)邏輯?

我想與網站進行接口以下載XML Background.xml文件,並下載另一個文件(Background.bmp),該文件位於此遠程服務器上。該文件是位圖,XML是關於位圖的元數據。我下載文件後,我想將其設置爲我的背景。我想從背景設置代碼中分離出文件下載代碼,但我不確定我會使用哪種設計模式。

這似乎是一個典型的演示/數據/業務應用程序,其中Form是表示層,背景設置器/ XML分析器是業務層,下載器是數據層。但我不確定哪種設計模式可用於實際數據訪問,因爲它來自網站而不是數據庫(所以DAO可能不適合這樣做)。我也購買了Wikipedia的設計模式,但沒有什麼看起來不錯。這是我可以使用MVC的東西嗎?

數據層

public class DataLayer { 
    public void DownloadFile() { 
     // download the file from http 
    } 
    public void GetXmlMetaData() { } 
} 

業務層

public class BusinessLayer { 
    private static BusinessLayer m_instance = new BusinessLayer(); 
    public static Instance BusinessLayer { get { return m_instance; } 
    private BusinessLayer() { } 

    public void SetNewWallpaper() { 
     // download the file from data layer 
     // set it as the background 
    } 
    public String GetWallpaperInfo() { return String.Empty; } 
} 

表示層

public class PresentationLayer { 
    public void HandleButtonClick(Object sender, EventArgs e) { 
     BusinessLayer.Instance.SetNewWallpaper(); 
    } 
} 

何我會將數據訪問部分與背景設置邏輯分開嗎?

回答

1

我很好奇,什麼是最好的設計模式在 使用下面的實現

基於什麼樣的標準?下載一個文件並用它做X,與構建飛機維護和零件跟蹤系統不一樣。複雜性,軟件生命週期,團隊規模,預算,時間框架,都影響「最佳方法」

一旦您知道爲什麼要應用哪種軟件設計原則,那麼它就更容易落實到位。

我想將文件從背景 設置代碼 下載代碼中分離出來,但我不知道我會用它的設計模式。

爲什麼?是的,這是很好的做法,但有理由分開。 a)將所有代碼放在一個方法中是一個極端。這個方法是一個極端的方法。 b)在班級中使用許多方法。升級
c)下一步在項目中分開課程。基本OO
d)在解決方案中製作單獨的項目。更多的設計模式
e)建立溝通的獨立解決方案。另一個極端。

你很可能在看C)或D),因爲你喜歡應用設計原則。

您選擇的選項可以有自己的變體,例如依賴注入/控制模式的反轉。但即時通訊建議你不要試圖在前面做這件事。聽起來像你的應用程序的矯枉過正。

這似乎是一個典型的表現/數據/業務應用

是確實的,但項目的90%以上會以某種方式。有沒有多少點數據你不出席。沒有數據的演示文稿沒有多少意義。

鑑於你的代表近2K的發佈時間,你顯然可以編碼。 所以我要建議: 用3個項目構建解決方案。

  1. 數據訪問
  2. 業務層
  3. 演示文稿。
  4. 只需簡單類(波蘇斯)和基本對象的邏輯
  5. 依賴注入/控制

考慮4或5只有非常熱衷,並且DI的反轉的核心示範項目/ IOC可能是最好的左直到您對1/2/3/4類型解決方案感到滿意爲止。

避免從前端項目引用/調用數據訪問項目。

核心模型不應該引用其他項目。

這是我可以使用MVC的東西嗎?

是的,你可以。前端項目有一個控制器(或2)控制器在前端項目中「調用」視圖。視圖僅顯示並獲取用戶的數據。控制器調用另一層。例如Controller調用業務流程層可以對數據層進行多次調用以獲取所有必需的信息並進行更新。

如果您想了解更多關於MVC的信息,請點擊這裏http://www.asp.net/mvc/tutorials。 這些教程並不總是「乾淨地」分開,因爲他們專注於MVC方面。 Infact您將在控制器中看到數據訪問。出席者在實際項目中永遠不會做的。

使用基本MVC模式的單個項目對於小型應用程序已足夠。多個項目使「演示」變得複雜。但想象一下你想要一個Windows WPF版本的應用程序。並在MVC項目中看到數據訪問代碼。那裏沒有太多的重用。這更好地解釋了爲什麼分離是好的原因。

好運...

1

您正處於模式化階段。很多人都經歷了這個階段。當你瞭解模式時,它會出現,學習其中的一些模式,並且已經想要將它應用到可以應用的地方。

嘗試使用某種模式編寫代碼來實現其中的一些模式,這不是最佳實踐。不要爲代碼本身編寫代碼。嘗試以最簡單,更簡潔的方式解決業務任務,這是最好的方法。模式應該可以幫助你做到這一點。

你已經分開了你的代碼的不同層次,這很好。你的架構非常簡單,你接近MVC。我認爲你應該停止在這一點上不要增加複雜性。

關於DAO,它表示數據訪問對象。沒有關於數據庫的任何詞。 DAO可以爲您提供對任何數據源的訪問:數據庫,緩存,nosql存儲,文件,數據倉庫(您的案例)等。這非常棒,因爲您可以動態更改應用程序的數據源,只需在它們之間進行切換。