我的Article資料庫中有一個物體:
public class Article
{
public Guid Id { get; set; }
public string Heading { get; set; }
public string Author { get; set; }
public string Content { get; set; }
public DateTime CreatedOn { get; set; }
public DateTime UpdatedOn { get; set; }
public int ViewsCount { get; set; }
public ImageData Image { get; set; }
public IEnumerable<Comment> Comments { get; set; }
}
對于我擁有的創建ArticleInputModel,以及顯示詳細資訊視圖,我擁有ArticleDetailsModel,并且對于我擁有的更新ArticleUpdateModel(等等......)
但是,這些模型具有相同的屬性。
- 如果這意味著代碼重復,我應該分開這么多嗎?
- 我嘗試遵循 SRP 但這似乎違反了 DRY 原則?
- 我是否忽略了什么?
uj5u.com熱心網友回復:
如果這意味著代碼重復,我應該分開這么多嗎?
通常,在使用單個物體的模型類(資料傳輸物件;DTO)時,您可以識別具有潛在不同屬性集的三種情況:
- 物體創建
- 物體讀取(顯示、查看)
- 物體更新
然而,可能有更多的子型別——例如創建或更新物體的不同方式、部分更新與完全更新、各種顯示,例如完整視圖、某種部分視圖、串列中物體的視圖等。
在構建 DTO 時有一個系統是有意義的,這樣您就可以在創建、讀取、更新操作方面區分創建、讀取(查看)、更新DTO。您可以看到此類 DTO 和 CRU(D) 操作之間存在明顯的相似性(洗掉操作通常沒有 DTO)。
無論您使用何種特定命名,此類分類都有助于代碼的未來可維護性:如果將來您需要引入一個屬性,該屬性可能不會在物體創建期間設定,但可以在更新期間更改,反之亦然,無需對代碼的不相關部分進行大量更改即可輕松實作,例如您只更改更新路徑,但避免更改創建路徑。
我嘗試遵循 SRP 但這似乎違反了 DRY 原則?
提供模型 (DTO) 類在語意上是不同的,那么我不認為這違反了 DRY。然而,這可能是主觀的。
將 DTO 視為次要物件。主要宣告是資料庫物體,它是資料模型的一部分。DTO 形式的此類物體的各種視圖取決于此物體宣告。只要您public SomeType PropName { get; set; }在 DTO 中保持簡單,就不會違反您無法忍受的 DRY。此外,例如在物體宣告中保留解釋各種屬性的注釋是有意義的,而不是將它們復制到 DTO 中(除非您必須生成一些 API 檔案,但這也可以解決<inheritdoc/>)。重要的是物體和 DTO 及其角色之間的明確區別。
uj5u.com熱心網友回復:
如果您正在創建文章的新實體,它的 ID 是什么?
或者作為一個更清楚的例子,它的 UpdatedOn 日期是什么?
你如何更新還不存在的東西?
您可能很快會遇到的另一個問題是,您將如何回傳特定作者的所有文章的串列?
在文章表中,您應該將作者存盤為作為外鍵鏈接到作者表的 Id(假設只能有一個作者)。
如果您的文章表現在看起來像這樣...
public class Article
{
public Guid Id { get; set; }
public string Heading { get; set; }
public Id Author { get; set; }
public string Content { get; set; }
public DateTime CreatedOn { get; set; }
public DateTime UpdatedOn { get; set; }
public int ViewsCount { get; set; }
public ImageData Image { get; set; }
public IEnumerable<Comment> Comments { get; set; }
}
...您可能會開始看到單獨的 ViewModel/DTO 在哪里發揮作用。
創建
public class CreateArticle { public string Heading { get; set; } public IEnumerble { get; set; } public string Content { get; set; } public string Image { get; set; } }
您正在創建一篇新文章,因此可能會插入一個自動生成的 Guid 作為鍵。您也很可能將當前日期/時間作為 CreatedOn 日期。Author 將來自某個描述的查找串列,因此您需要將某種串列傳遞到視圖中(上面簡化為 IEnumerable)。影像很可能是從影像位置的路徑提供的,因此您可能希望顯示為文本框。
添加
public class AddArticle { public string Heading { get; set; } public Id Author { get; set; } public string Content { get; set; } public ImageData Image { get; set; } }
填寫完創建表單后,現在要將其添加到資料庫中。在這種情況下,您的 DTO 需要以資料庫期望的格式添加資料。因此,您現在將在其他地方進行一些處理后傳遞選定的作者 ID 和 ImageData。
您仍然不需要文章 Id 或 CreatedOn,因為一旦此 DTO 已驗證,這些將被添加。
- 詳細資訊和查看
Hopefully you're now seeing the slight differences that make the ViewModel a valuable asset. You might also require something like the following to show the details of an Article as opposed to viewing the Article itself:
public class DetailOfArticle
{
public Guid Id { get; set; }
public string Heading { get; set; }
public Author Author { get; set; }
public string Content { get; set; }
public string CreatedOn { get; set; }
public string UpdatedOn { get; set; }
public int ViewsCount { get; set; }
}
public class ViewArticle
{
public Guid Id { get; set; }
public string Heading { get; set; }
public string Author { get; set; }
public string Content { get; set; }
public string CreatedOn { get; set; }
public string UpdatedOn { get; set; }
public int ViewsCount { get; set; }
public ImageData Image { get; set; }
public IEnumerable<Comment> Comments { get; set; }
}
Notice that the details might pass in an Author entity so that you can supply more information (this could also be exploded out into separate properties). You might also want to pass the date (and/or time) as a string after formatting etc.
The Article detail probably wouldn't need the comments as it's essentially the meta-data about the Article whereas the Article view is the Article as you'd want to present it for reading.
轉載請註明出處,本文鏈接:https://www.uj5u.com/net/331411.html
上一篇:使用Json.NET,如何合并兩個需要序列化的C#物件?
下一篇:GS1條碼決議——好像沒有分隔符
