2010-05-23 65 views
0

對於C#我還是比較新的,我正試圖確定構建新程序的最佳方式。這是我想要做的,我想反饋我的想法。設計佈局/模式

  • 表示層
  • 業務層(單獨的類庫)
  • 數據層(單獨的類庫)
  • 模型層(單獨的類庫)

什麼我掙扎是如果可以讓數據層和業務層中的類繼承我在Model Layer中定義的類型。通過這種方式,我可以根據需要在我的業務層中擴展類型,並使用任何我認爲合適的新屬性。我可能不會在我的業務層類中使用模型類型中的每個屬性,但這真的是一個大問題?如果這還不夠清楚,我可以嘗試一個例子。

+0

從你的名字我會猜測這是一個WPF應用程序,是正確的? – R0MANARMY 2010-05-23 03:37:34

+0

你是對的。 – user337816 2010-05-23 03:44:01

回答

5

一般的做法是使用的封裝,而不是繼承,用於圖層轉換。考慮以下兩種範式(如果我理解正確)

Model/Data Layer: 
    Customer 
    Order 

Business Layer: 
    MyCustomer : Customer 
    MyOrder : Order 

Model/Data Layer: 
    Customer 
    Order 

Business Layer: 
    MyCustomer (encapsulates Data.Customer) 
    MyOrder (encapsulates Data.Order) 

有去第一(繼承)路由時兩個主要問題:

  1. 當你修改基礎(數據/模型)類,你不得不改變業務類。
  2. 獲取對象關係很困難,通常需要非多態的方法。 I.E.如果模型或數據層在Customer對象上公開了一個集合Order,那麼讓類MyCustomer暴露一組MyOrder對象變得困難而且「笨拙」。

利用封裝處理這兩個問題,絕對是我推薦的路線。看你的名字

,我假設你正在尋找寫一個WPF應用程序。如果是這種情況,請查看Model-View-ViewModel (MVVM)設計模式。

+0

你幾乎擊中了頭部。因爲我對這個還是比較新的。我理解關於房地產的封裝概念,但我不認爲我理解它在這種情況下如何適用。你能再詳細一點嗎? – user337816 2010-05-23 03:50:44

+0

+1爲跨層封裝的核心概念。 – 2010-05-23 04:03:06

+0

針對MVVM的+1。 @wpfwannabe,我掙扎了幾個星期學習MVVM直到我看了這部影片:http://www.lab49.com/files/videos/Jason%20Dolinger%20MVVM.wmv 我真的建議你給它一個看你做了之後玩了WPF一段時間。祝你好運! – bufferz 2010-05-23 12:15:14

0

我認爲一個例子會很好 - 我不認爲你的建議是必然不好,但這取決於你想要達到的目標。

你爲什麼要繼承模型層中的類?什麼是特定模型類的接口和目的,以及從模型類繼承的業務邏輯類的目的是什麼?

繼承是否真的有意義?

繼承會違反Liskov的替代原則嗎?

編輯:

wpfwannabe,我會小心使用繼承,只是因爲它似乎是容易的選擇。我特別提到了Liskov替代原則,因爲它涉及確定何時繼承是有效的。

另外,你可能也想看看「SOLID」的設計原則OO開發(包括里氏的替換原則):

http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

+0

在這個例子中我的模型層將包含具有代表性數據庫表的類型。簡單的包含屬性和構造函數的類。我想從業務層的模型類繼承將是一個好主意,所以我想有我所有的基本屬性,並根據需要,我可以創建新的。 – user337816 2010-05-23 04:01:56

0

是否把每一層的階級獨立的庫取決於您是否需要寫在未來將需要使用這些相同的類更多的應用。你可能會認爲你需要馬上開始做。根據我的經驗,編碼後至少有某種概念證明,我開始有更好的想法。在項目中期的某個時刻組織代碼,比如重新分解,組織成圖書館等,很容易。它試圖在上線之前這樣做,這是危險的,而不是一個好主意。

關於你的問題的其餘部分,我要提到你,我從Martin Fowler的教訓,我不能說比他更好,如果我這樣做,我只是跟着他重複:

http://martinfowler.com/eaaCatalog/serviceLayer.html
http://martinfowler.com/eaaCatalog/