2011-09-05 60 views
2

您如何在應用程序中管理大型網址(包含大量查詢參數)?

例如,看一下來自eBay這個鏈接(不要點擊鏈接只是一個大的URL的一個例子):如何用很多查詢參數管理URL?

http://www.ebay.com/sch/Cameras-Photo-/625/i.html?LH_ItemCondition=1&LH_Price=15..500%40c&rt=nc&LH_Auction=1&LH_BIN=1&_nkw=nikon&_catref=1&_clu=2&_fcid=12&_fln=1&_localstpos=&_mPrRngCbx=1&_sc=1&_sop=15&_stpos=&_trksid=p3286.c0.m283&gbr=1

你可以看到很多則params的,其中不乏有奇怪,短的名字,如「_F」,「_sc」等

你不能使用你的應用程序的參數,可以你需要轉換的東西更「可讀」:

$readableName = $_GET['_f']; 

,但隨後你最終有很多瓦爾的,而且很可能你需要所有的人都在一個功能,所以,不是每一個查詢參數一個新的變種,我們可以使用數組:

$readableParams['readableName'] = $_GET['_f']; 

但後來我們結束有一個大陣列具有任意結構的,所以我認爲最好的辦法是有一個VO(DTO)對於那些參數,可以是這樣的:

$filterVo = new FilterVo(); 
$filterVo->readableName = $_GET['_f']; 

這是確定的,但在這裏我們把這些代碼?我的意思是,從「罕見問詢參數」轉換爲「明確價值對象」的最佳地點在哪裏?
因爲我們也需要反過程,所以我們可以用數據創建一個VO,然後使用該VO中的正確查詢參數生成一個URL。

VO裏面? 助手URL類? 查看模型基類?

你如何管理這些網址有很多參數?

回答

1

有趣的是,你提出的輸入名稱是神祕的。我將從我的項目中看到的一般意義上回答(不僅僅是PHP的具體內容),我認爲這個主題與此有關。一般方法:

  • 表單變量通常映射到一個對象。它是PHP中的VO或Java中的Beans。這將是最可讀的轉換形式(在我看來),因爲它提供了正在轉換的HTML表單的上下文
  • 在很多情況下,我見過某種Form Utilities Helper類,它將處理轉換和來自。但是,這不是一個特定的硬編碼轉換,大多數轉換是非常結構化和通用的。例如,它採用所有的getters/setters方法並將其用作表單名稱。例如,我可能在我的對象中有getUsername(),然後Form Utilities會將其翻譯爲<input name="username"/>
  • (可選)您也可以通過映射覆蓋覆蓋默認映射。這可以採取以下形式:
    • 配置文件,例如將實例變量映射到表單變量的XML文件。在上面的例子中,這樣的映射可以將用戶名實例變量映射到一個更加神祕的形式變量,名稱爲:如Java中的註釋或C#中的屬性等語言特徵。語言功能將允許在沒有我見過的,將有基類的VO /豆有fromForm(input)toForm()利用項目配置文件,但內聯對象源代碼本身
  • 要進行的映射上面提到的表單實用程序。它提供了方便開發人員,使他們不必處理表單工具,但只需撥打toForm()fromForm(input)從他們的對象來處理改造

現在給上面的圖案,神祕的表單字段,我通常看到:

  • 創建VO對象來表示字段
  • 創建映射配置到隱蔽字段的實際實例變量與邏輯名稱
  • 要麼使用形式公用事業輔助CLA映射SS直接,或如果在基類中使用的表格工具,使用便利方法toForm()fromForm(input)
+0

我選擇使用助手類(my views/view_model使用該類)來生成* all *我的鏈接,他們接受VO並返回鏈接。逆過程在適當的controller_action內。無論如何,我不確定這個解決方案,因爲將VO轉換爲RequestParams的代碼現在在兩個不同的地方。我不知道如何用POST params解決這個問題(POST請求不是鏈接,所以也許我需要一個額外的FormParamsGenerator助手)。也許在VO中使用toParam和fromParam更清潔(如果我們使用一個接口,甚至更多),我希望這是一種常見模式:( – Enrique

+0

我同意在VO中使用to和from本身更清潔。答案,在VO中可以調用Form Utilities(幫助程序類)以便工作。至於你的POST與GET參數,你想要做的是將數據結構概括成你傳遞給你的幫助類的鍵值對的表結構(而不​​是使它成爲GET和POST特定數據),並將此輔助類擴展爲PostFormUtilities和GetFormUtilities,他們的工作是翻譯POST/GET的特定數據並將其轉換爲廣義表鍵值數據。 – momo

+0

要回答你的問題,這是否是常見模式,答案是肯定的。不僅用於HTTP參數之間的映射,而且是任何類型映射(特別是DB到VO映射或XML到VO映射)的常見模式。在許多這些場景中,您將在VO或Utility類中具有等同於和來自函數的功能。如果你需要更多的澄清,讓我知道,我可以更新答案 – momo

0

大多數這些參數是自動生成的。我在很多ASP.NET應用程序中看到過這種行爲。我討厭.NET做這樣的事情,但我不想從開始

大多數情況下,這些附加參數是通過嵌入模塊生成的。這些工作是以一種自動化的方式進行的,這些工作並不直接反映在應用程序中(應用程序開發人員至少編寫的部分),或者協助其他任務。這是跨請求維護狀態的一種方式。

另一方面,你可以實現你描述的這種機制。在MVC環境中,該任務將由控制器處理。這隻有在你有很多GET參數通過時纔有意義。你應該嘗試從一開始就避免這種做法。

+0

是的,我有一個MVC框架的工作,問題是真的,我有很多的GET參數(如ebay的鏈接)。控制器是讀取這些參數的正確位置,因此可以轉換爲一些VO/DTO,但是在哪裏進行逆向處理?你如何生成鏈接?這應該是View(或View_Model)的一部分,但是我們在兩個不同的地方將URL轉換和映射到VO。 – Enrique

+0

理論上這個任務也是控制者的責任,因爲控制者負責處理「請求」,無論我們是否準備下一個。 – thwd

+0

我認爲這是錯誤的,如果您使用該模式,則生成鏈接是View的一項任務,或者甚至更好的View_Model。我的控制器不知道如何生成視圖,只需要調用view_model,也可以通過任何視圖生成鏈接,因此可以從您的視角生成任何控制器,這會帶來很多幹擾問題。現在我有一個用於生成鏈接的輔助類,該類使用參數和Route類,並由View_Model使用。 – Enrique