服務層和存儲庫的責任

我需要一些建議，指出我的服務和存儲庫在哪裏畫線。服務層和存儲庫的責任

public class Contact 
{ 
    public Guid Id {get;set;} 
    public string Username {get;set;} 
    public Guid? AvatarId {get;set;} 
    public Avatar Avatar {get;set;} 
} 

public class Avatar 
{ 
    public Guid Id {get;set;} 
    public string FullSizeImagePath {get;set;} 
    public string ThumbnailSizeImagePath {get;set;} 
}

讓我們假設阿凡達模型將只用於聯繫人模型，並且它是聯繫人的可選屬性。我的存儲庫是否應負責爲聯繫人添加頭像或者業務/服務層是否應擴展該功能？人們可以爭辯說，擁有一個化身是一項業務需求，但由於它是模型的一部分，因此數據層應該知道如何處理它。

我建議我們可以添加功能來添加/更新和通過存儲庫刪除頭像。業務/服務層將負責保存物理文件，驗證以及在存儲庫上調用適當的方法。所有存儲庫關心的是附加適當的聯繫人併爲其添加化身。

我的思考過程是，由於頭像只在聯繫人上使用，目前我們會擴展存儲庫，從而爲DAL添加功能。這可能對單獨的API有用。

來源

2012-01-18 DDiVita

Offtop，爲什麼在'Contact'類中需要'AvatarId'屬性，因爲您可以通過'Avatar.Id'來訪問它？ – sll 2012-01-18 18:53:58

@sll我認爲這是實體框架（代碼優先）所需要的，以幫助定義導航屬性Avatar – 2012-01-18 18:55:56

@sll：我將它用於實體框架的導航和映射。我可以告訴EF，數據庫中的頭像可以爲空。 – DDiVita 2012-01-18 19:01:14

在我看來，我不會將此添加到您的存儲庫，而是將其定義在您的業務層中。

如果您關注域名驅動設計，您的Contact將得到一個AddAvatar方法，該方法將負責創建Avatar並設置正確的屬性。

只爲聚合根目錄創建存儲庫。由於您已經聲明Avatar只能通過您的Contact訪問，因此您的數據層不應包含AvatarRepository。您可以通過相應的聯繫人加載Avatar。

您還聲明BLL將負責保存物理文件。我會認爲這一段時間。你真的想要處理BLL中物理文件的代碼嗎？

假設您將阿凡達文件移至數據庫以進行縮放和備份，原因是該代碼突然移至存儲庫。存儲庫是我們在思維過程中立即映射到數據庫的東西，但它是數據存儲的通用術語，它也可以存儲物理文件。我們不介意Repository如何實現這一點。我們關心的是將業務邏輯寫入業務問題，而不是擔心基礎設施問題。

所以，我會將創建和更新Avatar的代碼移動到您的BLL以及處理物理文件的代碼Repository。

來源

2012-01-18 20:12:16

我從來沒有真正想過物理文件通過存儲庫。完美的感覺！舊的習慣，我想。 – DDiVita 2012-01-18 20:28:41

存儲文件是您的基礎設施的一部分但確實，舊的習慣:-) – 2012-01-18 20:43:37

服務層和存儲庫的責任

回答

相關問題