Struts2 - 多種方法的動作？

Question

我是這個網站的新手，這是我的第一個問題。

我必須做一個網站，我正在使用java和Struts2，但我是Struts2的新手。

在我的網站中，我必須向Facebook提出請求並通過OAuth進行身份驗證。

我正在執行操作頁面的執行方法中的所有過程（驗證和請求受保護的資源），這個過程非常復雜，並且在Facebook和我的網絡之間有很多重定向。

前幾天我讀到了“不要用多種方法創建動作：”執行“並且你想要執行的操作（例如”createUser“）應該足夠了”（來自http://freeopenidea.blogspot.com.es/ 2010/04 / struts2-best-practices.html ）。

大多數代碼可以在另一個時刻從我的網站的另一部分調用，因為我在第一次連接時執行此過程但我可以執行此操作（或類似的東西）來刷新聯系人列表。

1 - 我應該為我需要的方法創建一個單獨的類（不是動作），並從“execute”方法調用它們嗎？

2 - 我應該將代碼保留在操作頁面中，而不是“執行”之外的方法嗎？ 每當我需要完成一些任務時，請調用此頁面。

我不知道在哪里放置代碼（我知道，我必須存儲de accessToken。我只是粘貼代碼來顯示復雜性，但不要查看更正）。

public String execute() throws Exception{
   if (code!=null){
      Verifier verifier = new Verifier(code);
      //get the accessToken to do requests
      Token accessToken = service.getAccessToken(EMPTY_TOKEN, verifier);
      OAuthRequest requestList = new OAuthRequest(Verb.GET, PROTECTED_RESOURCE_URL);
      service.signRequest(accessToken, requestList);
      Response responseList = requestList.send();
      if (responseList.getCode() == 200){
        //I get the Friends List
        JsonParse parser = new JsonParse();
        JSONObject json = (JSONObject) JSONSerializer.toJSON(responseList.getBody());
        JSONArray datos = json.getJSONArray("data");
        for (Object o : datos) 
        {//for every friend of the list I do this
            JSONObject elem = (JSONObject) o;
            String id = elem.getString("id");                
            OAuthRequest requestFriend = new OAuthRequest(Verb.GET,"https://graph.facebook.com/"+id);
            service.signRequest(accessToken, requestFriend);
            Response responseFriend = requestFriend.send();
            if (responseFriend.getCode() == 200){
                JsonParse parserAux = new JsonParse();
                PerfilContacto pcBean = parserAux.parseFacebookElement(responseFriend.getBody());
                pcDAO.insertarContacto(pcBean); 
            }
        }
      }
      return SUCCESS; 
   }      
   else return ERROR;    
 }

Answer 1

IMO在動作方法中的代碼太多了。 操作應該處理Web和業務層之間的層，而不是其他。 這種級別的耦合，特別是對於硬編碼的類實例化，使得很難單獨測試動作的邏輯。

將所有代碼基本上移到服務中。 該操作僅涉及服務交互。 該框架驗證了code的存在。 該服務在Struts 2之外進行測試。該操作使用模擬服務進行測試。

完全未經測試，但我懷疑我的代碼看起來更接近下面的內容。 它將一種復雜性換成另一種，但帶來了多種好處。 每種方法都緊密集中且易於閱讀。 服務調用是隔離的，這允許我們測試不同的服務失敗模式。 它是系統行為和功能的粒度表示。

行動

public String execute() throws Exception {
    fbService.updateFriends(code);
    return SUCCESS;
}

FB服務

public void updateFriends(String code) {
    Token accessToken = getAccessToken(code);
    Response response = getFriends(accessToken);
    if (response.getCode() == 200) {
        processFriends(accessToken, response);
    }
}

private void processFriends(Token accessToken, Response response) {
    JSONObject json = (JSONObject) JSONSerializer.toJSON(response.getBody());
    JSONArray datos = json.getJSONArray("data");
    for (Object o : datos)  {
        JSONObject friend = (JSONObject) o;
        processFriend(friend);
    }
}

private void processFriend(Token accessToken, JSONObject friend) {
    Response response = getFriendGraph(accessToken, friend.getString("id"));
    if (response.getCode() == 200){
        PerfilContacto pcBean = new JsonParse().parseFacebookElement(response.getBody());
        pcDAO.insertarContacto(pcBean); 
    }
}

//~ Service interaction

private Response getFriends(Token accessToken) {
    return sendSignedGetRequest(PROTECTED_RESOURCE_URL, accessToken);
}

private Response getFriendGraph(Token accessToken, String id) {
    return sendSignedGetRequest("https://graph.facebook.com/" + id, accessToken);
}

private Token getAccessToken(String code) {
    return service.getAccessToken(EMPTY_TOKEN, new Verifier(code));
}

private Response sendSignedGetRequest(String url, Token accessToken) {
    OAuthRequest request = new OAuthRequest(Verb.GET, url);
    service.signRequest(accessToken, request);
    return request.send();
}

如果我們考慮指標，我們最終會得到以下結果。

原版的：

Average Function NCSS:      24.00
Average Function CCN:        6.00
Program NCSS:               25.00

重做：

Average Function NCSS:       3.63
Average Function CCN:        1.38
Program NCSS:               31.00

最終，它意味着：

• 重要LOC的數量沒有增加太多。
• 每個功能<4行（易於閱讀）。
• 每個函數的圈復雜度<2（易於測試和推理）。
• 程序讀起來更像它正在做的事情，允許更快的理解。

權衡是我們有更多的方法（鑒於任何合理的IDE或文本編輯器，這不應該是一個巨大的問題），這是一種復雜性。 然而：

• 我們可以在我們選擇的深度停止閱讀。
• 我們可以用更大的粒度進行測試。
• 我們可以確定我們可能錯過的成功/失敗模式。
• 我們可以更輕松地交換和/或擴展功能。