/**獲取角色對應(yīng)權(quán)限*/
@RequestMapping("/listByRoleId")
public CommonResult<List<MenuVo.ListByRoleIdVo>> listByRoleId(@Valid MenuParam.ListByRoleIdParam param){
return menuService.listByRoleId(param);
}
@Data
public static class ListByRoleIdParam {
@NotNull(message = "不能為空")
private Integer roleId;
}
@Data
public static class ListByRoleIdVo {
private Integer menuId;
private String name; //名稱
private Integer pid; //父id
}
我現(xiàn)在項目里面使用上面這種形式來寫代碼.每個方法的參數(shù)定義成一個類.方法的返回值也定義成一個類.這樣寫主要是想使用valid來做參數(shù)校驗,將參數(shù)封裝成一個對象也方便使用反射來調(diào)用方法.
這樣就會導(dǎo)致項目里面有很多這種參數(shù)和返回值的類.請問這種寫法出了類定義的多點,還有什么不好的地方? 會影響性能嗎?
4 回答
一只名叫tom的貓
TA貢獻(xiàn)1906條經(jīng)驗 獲得超3個贊
謝邀。有很多這種參數(shù)和返回值的類,其實即使你不做校驗用，也應(yīng)該這么寫，參數(shù)封裝成對象理所當(dāng)然，只不過很多類有業(yè)務(wù)重復(fù)的情況下可以抽象、繼承的方式來做。因為業(yè)務(wù)需求問題，校驗多種多樣，代碼這種bean變多，其實也沒什么影響，只想便于維護(hù)就好；
慕碼人2483693
TA貢獻(xiàn)1860條經(jīng)驗 獲得超9個贊
顯然是太靈話, 修改邏輯要重新定義類, 類的序列化緩存也要考慮升級時的版本兼容的問題.
要看有多少,幾十個的話不用太在意. 好處是有強類型驗證.
如果很多的話建議還是用抽象的Map來存參數(shù). 這樣可以把參數(shù)與邏輯剝離.
慕容3067478
TA貢獻(xiàn)1773條經(jīng)驗 獲得超3個贊
如果確實有這個需求的話，不為特定的接口參數(shù)寫對應(yīng)的數(shù)據(jù)類，也得寫一串JSON解析代碼，相較而言寫類是更好的方式。
也可以考慮使用GraphQL來設(shè)計接口的參數(shù)，不過也要寫Scheme，但是更為靈活
添加回答
舉報
0/150
提交
取消