好吧，我將我的 Web 應(yīng)用程序劃分為模塊。每個模塊都通過 Facade 與其他模塊進行通信，這是唯一的入口點。控制器也通過外觀與模塊通信。外觀中的方法需要一些 DTO 并執(zhí)行一些業(yè)務(wù)邏輯。在 90% 的情況下，控制器映射 1-1 外觀方法的 DTO 參數(shù)的請求。我的問題是：使用相同的類在控制器中獲取請求然后在外觀中用作 DTO 是一種好習慣嗎？
1 回答
天涯盡頭無女友
TA貢獻1831條經(jīng)驗 獲得超9個贊
我不會說有絕對正確的方法可以做到這一點。
如果您的應(yīng)用程序相當簡單，例如，只是用于創(chuàng)建和獲取數(shù)據(jù)的數(shù)據(jù)庫操作、簡單的數(shù)據(jù)模型并且沒有復(fù)雜的業(yè)務(wù)邏輯，那么使用相同的 DTO 可能會很好。這種情況大多不是真的。
但是，如果您的應(yīng)用程序需要處理相當多的業(yè)務(wù)“用例”，那么最好將您的核心域?qū)訉ο笈c用于與外部系統(tǒng)（如 API 或消息隊列）交互的對象分開。
如果你舉個例子（有點做作的用例來說明我的觀點）：
假設(shè)用戶現(xiàn)在可以通過 ReST 端點在您的應(yīng)用程序中創(chuàng)建客戶，并且有一個定義良好的請求模型：
class CustomerDTO {
private String firstName;
private String lastName;
private String companyId;
private String email;
private List<String> subscriptions; // customers subscribe to services
}
假設(shè)，您的域模型：
class CustomerBO {
private String name; // firstName + lastName
private String companyId;
private String email;
private List<String> subscriptions; // customers subscribe to services
}
稍后，如果您想通過從消息隊列或 CSV 文件中讀取實體來添加創(chuàng)建實體的功能 - 您的應(yīng)用程序可能是下游系統(tǒng)從另一個應(yīng)用程序獲取饋送。在這種情況下，您與 API 用例有以下區(qū)別：
每個客戶只有 1 個訂閱（總是）
名稱作為單個字段發(fā)送
沒有電子郵件，因為這些客戶不是真正的人類用戶（也就是說，沒有要發(fā)送的電子郵件，沒有登錄等）
因此，您的請求模型如下所示：
class FeedCustomerDTO {
private String name;
private String companyId;
private String subscriptionId;
}
現(xiàn)在，應(yīng)用程序核心只接受CustomerBO. API 和 Feed 模塊將請求模型轉(zhuǎn)換為一致的域模型。您可以看到，CustomerBO在這兩個用例中保持一致有助于您保持應(yīng)用程序核心清潔并與交互分離。
希望這有意義并解決您的查詢。
添加回答
舉報
0/150
提交
取消