ABP理論學習之驗證DTO

返回總目錄

首先應該驗證應用的輸入。使用者或者其它應用都可以向該應用傳送輸入。在乙個web應用中，驗證通常要實現兩次：在客戶端和伺服器端。客戶端的驗證大多數情況下是為使用者體驗而實現的。在客戶端最好先檢查一下表單，並向使用者展示不合法的字段。但是服務端的驗證更關鍵且不可避免。

服務端的驗證通常實現在應用服務層。應用服務方法應首先檢查（驗證）輸入然後再使用它。abp提供了乙個很好的基礎設施來驗證應用服務方法的輸入。

應用服務方法接收乙個dto（資料傳輸物件）作為輸入。abp有乙個ivalidate介面，凡是實現了該介面的dto都可以自動地進行驗證。因為iinputdto繼承了ivalidate，因此只要為輸入dtos實現iinputdto就可以確保驗證了。

abp支援資料註解特性。假設我們要開發乙個任務（task）應用服務，該服務用於建立乙個任務，它的輸入引數型別如下所示：

public class createtaskinput : iinputdto
[required]
public string description 
}

這裡，description屬性標記為required。assignedpersonid是可選的。在system.componentmodel.dataannotations命名空間中也有很多特性（如maxlength,minlength,regularexpression等等）。來看一下任務應用服務的實現：

public void createtask(createtaskinput input)

;if (input.assignedpersonid.hasvalue)

_taskrepository.insert(task);

}}正如你所看到的，這裡沒寫驗證**，因為abp會自動進行驗證。abp也會檢查輸入是否為null。如果為null，就會丟擲abpvalidationexception。因此，你也不用寫檢測null的**（保衛語句）。如果輸入的屬性有任何乙個是非法的，那麼就會丟擲相同的異常。

該機制和asp.net mvc的驗證相似，但是注意的是應用服務類不是派生自controller，而只是乙個純粹的類並且在web應用之外工作。

如果資料註解還不能滿足你的情況，那麼你可以實現icustomvalidate介面，如下所示：

public class createtaskinput : iinputdto, icustomvalidate
public bool sendemailtoassignedperson 
[required]
public string description 
public void addvalidationerrors(listresults)
}}

icustomvalidate介面宣告了要實現的addvalidationerrors方法。這裡，我們有乙個sendemailtoassignedperson屬性。如果它的值是true，而且沒有提供assignedpersonid或值是負數，那麼我們就認為這裡發生了驗證錯誤，我們必須將validationresult物件新增到results集合中。

我們可能在驗證之後執行乙個額外的操作來排列dto引數。abp定義了ishouldnormalize介面，該介面中定義了normalize方法來達到排列dto引數的目的。如果你實現了該介面，那麼就應該在驗證之後（方法呼叫之前）呼叫normalize方法。假如我們的dto要有乙個排序（sorting）方向，如果沒有提供的話，我們就要設定乙個預設值：

public class gettasksinput : iinputdto, ishouldnormalize
public void normalize()
}}

ABP理論學習之驗證DTO

ABP理論學習之驗證DTO

ABP理論學習之Abp Session

ABP理論學習之開篇介紹

ABP理論學習之驗證DTO

ABP理論學習之驗證DTO

ABP理論學習之Abp Session

ABP理論學習之開篇介紹

相關推薦