我應該在存儲庫界面之外創建存儲庫項目嗎？

Question

一位同事正在使用“實體和 Dtos”的約定在我們的應用程序中實現存儲庫模式。 這是他的想法，我不熟悉成語。

目前，實體和Dtos之間的主要區別是：

• 實體有一個 ID 字段（Dtos 也有，我覺得很臭）；
• Dtos 有一個Clone方法；
• 實體屬性具有更易於序列化的數據類型，轉換由數據映射器執行；

問題是：

我應該在客戶端自由創建我的 Dtos，然后將它們發送到 repo 嗎？ 或者我應該只在 repo 界面請求新的 Dto 實例？

這將是以下之間的區別：

TDto dto = new TDto();
// edit dto properties
repo.Add(dto)

和

TDto dto = repo.Add(); // repo : Repository<TDto>
// edit dto properties
repo.Update(dto);

有沒有更好的方法？ 如果這是一個偏好問題而我更喜歡第二種選擇，我應該注意不要把自己畫到某個角落嗎？

（免責聲明：坦率地說，我認為這個 Entity/Dto 對於我們相對簡單的客戶端桌面應用程序來說有點矯枉過正，它只有基於瑣碎的基於序列化的 CRUD 需求，但我願意遵循“模式”，只要它解決問題而不是獲取在路上）

更新：

我目前面臨並試圖解決的一個問題是“Smelly Id 屬性”。 目前，Id 是在添加時在 Dto 中設置的。 代碼是這樣的：

    public Patient Add(Patient patient)
    {
        patient.Id = Guid.NewGuid();
        var entity = patient.ToEntity();
        _patientsCache.Add(entity);
        this.Salvar();
        return patient;
    }

請注意，該方法調用返回相同的 Dto，只是現在其 Id 設置為由 repo 創建的值。 我的頭腦看着這個並認為“這是不對的”，但我無法令人信服地證明它的合理性。

Answer 1

最終，當涉及到復雜性和架構決策時，沒有“正確”的答案。 正如您所指出的，如果應用程序很小，在其中設計太多層可能會過分。 另一方面，如果應用程序變大，以后重構就更難了。

至於在哪里實例化DTO的問題； 這只是實例化。 如果您正在調用默認構造函數並且您的構造函數以一種無臭的方式運行 - 即它不執行復雜的邏輯或做有副作用的事情，而只是設置您的默認或“空”實例DTO——那么你在哪里做真的不重要。

我會說在客戶端這樣做，因為它更簡單並且可以為您節省一次往返。

如果您不希望您的客戶知道您的 DTO 中的“ID”字段，則將其設為internal字段或屬性，並將其設置在存儲庫代碼中。