4 回答

TA貢獻1830條經驗 獲得超3個贊
如果兩個 REST 端點必須返回相同的報告但公開不同數量的信息,那么您可能會發現@JsonView它很有用。
這是示例http://rsdn.org/forum/flame.politics/7430262
public class Views {
public static class Public {
}
public static class Internal extends Public {
}
}
public class Item {
@JsonView(Views.Public.class)
public int id;
@JsonView(Views.Public.class)
public String itemName;
@JsonView(Views.Internal.class)
public String ownerName;
}
@JsonView(Views.Public.class)
@RequestMapping("/items/{id}")
public Item getItemPublic(@PathVariable int id) {
return ItemManager.getById(id);
}
@JsonView(Views.Internal.class)
@RequestMapping("/items/internal/{id}")
public Item getItemInternal(@PathVariable int id) {
return ItemManager.getById(id);
}

TA貢獻1851條經驗 獲得超3個贊
我從“領域驅動設計”中學到的東西:不要試圖找到一個“銀彈”模型??偸怯胁煌姆绞絹肀磉_你的概念。模型總是依賴于上下文。
在這里,您report
的存儲方式是一種表示形式。您的 REST 客戶端想要讀取它的方式是另一種表示。您可以想象每個用例都有一個表示。
在這種情況下,我不會為每個應用層之間或域有界上下文之間的映射編碼經濟。
另外,我會避免繼承,如有必要,更喜歡一些接口,接受一些代碼冗余。

TA貢獻1810條經驗 獲得超4個贊
通常在應用程序的不同層之間存在對象分離,這意味著您可以擁有一個直接映射到數據庫的 Report 對象,但還有一組用于與客戶端通信的不同對象,您還可以擁有第三個對象一組對象,您的業務對象,它將包含與您的應用程序相關的邏輯。請注意,您將需要維護在這些對象之間轉換的邏輯,可能是構建器模式或類似的東西。作為一個小例子,讓我們考慮您的情況,您可以:
報告:類與數據庫的 1 對 1 映射,便于保存和檢索對象
ReportDAO:包含與 Report 相同的字段,但具有應用程序在處理這些報告時可能使用的附加功能(現在想不出任何東西)
ReportDTO/ExtendedReportDTO:您可以擁有多個繼承或不繼承的類,這些類將僅包含字段 + getter/setter,并用于與客戶端進行通信。
現在使用這個簡單的示例可能并不明顯,但是分離您的對象將使以后擴展和修改您的應用程序變得更加容易。目前,您可能在所有級別都擁有相同的信息,但稍后可能會發生變化,而且最好不要公開您的業務對象,因此如果您在應用程序中使用 Report 類,則共享不是一個好主意例如,它在 API 中。所以我想說你可以在這里使用繼承,但至少對我來說,我認為在應用程序和數據庫級別擁有這些相同的對象不是一個好主意。
添加回答
舉報