2010-08-04 79 views
4

我的問題陳述是:設計方法(域驅動或服務驅動)

我想寫設計文件管理(添加,複製,刪除等操作)。有兩種方法:

  1. 服務驅動方式只包含文件屬性

寫文件VO。對於例如


public Class File { 
    private boolean hidden; 
    private boolean read; 
    private boolean write; 

    public boolean isHidden() { 
     return hidden; 
    } 
    public void setHidden(boolean hidden) { 
     this.hidden = hidden; 
    } 
    public boolean isRead() { 
     return read; 
    } 
    public void setRead(boolean read) { 
     this.read = read; 
    } 
    public boolean isWrite() { 
     return write; 
    } 
    public void setWrite(boolean write) { 
     this.write = write; 
    } 
} 

並分離了與文件相關的操作的服務。對於例如:


public Class FileService { 
     public boolean deleteFile(File file) { 
      //Add delete logic. 
     } 
     //Same way you can add methods for Add and copy file. 
} 
  • 域驅動方法(我可能是錯在這裏。)
  • 其中file VO包含了所有屬性加所需的操作:

    
    public class File { 
        private boolean hidden; 
        private boolean read; 
        private boolean write; 
    
        public boolean isHidden() { 
         return hidden; 
        } 
        public void setHidden(boolean hidden) { 
         this.hidden = hidden; 
        } 
        public boolean isRead() { 
         return read; 
        } 
        public void setRead(boolean read) { 
         this.read = read; 
        } 
        public boolean isWrite() { 
         return write; 
        } 
        public void setWrite(boolean write) { 
         this.write = write; 
        } 
         public boolean deleteFile() { 
          //Add delete logic. 
         } 
         //Same way you can add methods for Add and copy file. 
    } 
    

    那麼這兩種方法的優點和缺點是什麼?

    回答

    4

    沒有太多關於您正在設計的系統的信息很難發音。對我而言,選擇取決於系統邊界。

    如果您需要提供作爲服務公開的且可供外部消費者訪問的API,請參閱解決方案1,這是唯一方法。如果你的系統是一個庫,其API將被其他應用程序內部使用,那麼就像在解決方案2中一樣,建立一個豐富的領域模型,這是更多的OO。您不希望使用沒有真正原因存在的服務,管理器和實用程序類來擴展您的API。

    但是,如果不知道最終目標,很難說。

    6

    在面向對象的語言中,將邏輯放在類本身而不是服務類中是典型的方法(以及更好的IMO)。它遵循「告訴,不要問」的原則,例如告訴文件刪除自己,而不是要求某些服務刪除它。背後的主要原因之一是允許繼承。例如,如果你有一個File的子類,並希望它在被刪除之前寫入一條日誌消息,那麼對於一個服務類來說很難做到這一點,因爲你需要爲每個子類使用不同的服務類。

    就面向服務的方法而言,這通常被認爲是更高層次的(即面向服務的體系結構)。考慮一個財務股票系統,你可能有一個「購買股票」服務和一個「賣出股票」服務。有一個對應於各個類別的服務類別(即知道如何買賣股票的股票服務)不會非常面向對象。

    您的系統中可能還有一個服務層,它提供了與其他外部服務(即數據庫)的集成點,但我不認爲這是您在這裏討論的內容。所以,我可以堅持將邏輯封裝在File類本身的方法。